RSF Discussions Forum

That's a matter of arranging the geometry of your application contexts. In Sakai this is what is done by the Sakai context listener - it registers the global Sakai Spring context as a parent of the webapp's context.

You can see one instance of the glorious code in action here:

https://source.sakaiproject.org/svn/component/branches/sakai_2-2-x/component-api/component/src/java/org/sakaiproject/component/impl/ContextLoader.java

The base class is documented here:

http://static.springsource.org/spring/docs/2.0.7/api/org/springframework/web/context/ContextLoader.html

You don't need to achieve this effect in this way - any other method of calling setParent on the new webapp's context will be effective -

http://static.springsource.org/spring/docs/2.0.7/api/org/springframework/context/ConfigurableApplicationContext.html#setParent(org.springframework.context.ApplicationContext)

Note that the method warns though that the parent should generally only be set during the constructor for an application context.

Where is your parent global context actually coming from?

Hi - the purpose of these "bridge" classes are to enable Java immutable classes to appear in Spring contexts as proxies. Since it is impossible to "fake out" an immutable class in Java, the only way to create a Spring bean which may dynamically take on a variable role of one of these classes is via a one-line interface (OLI! http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=OLI) class which returns the type (in this case, String).

The purpose of the "sakai-Context" bean is to allow a point of resolution and injection of some String representing the "Sakai Context" (in old-style Sakai, a site string reference), without causing pollution by dependence on the Sakai APIs. RSACStringBridge is a generalised helper which allows bridging such a proxy from application to request context - since in general the value of this String will be different in each active request.

I hope this helps you somewhat, although hopefully it also conveys that this is not really anything that you would need to bother with yourself, especially in a project outside of Sakai, where you would be blissfully unbothered by the intrusion of undesirable dependencies.

Look out for "Fluid Kettle" - coming soon, an all-Javascript serverside embodiment of the RSF concepts delivered as a tiny minimal Java Servlet... an XML-less, Java-less dawn

- together with a super-lightweight all-Javascript IoC system.... "there are greater madmen even than I".

Thanks, Lovemore - I will look into making this behaviour configurable.

Hi there - thanks for this report, Lovemore - the behaviour is certainly less than ideal. However, we are somewhat at the mercy of the underlying YUI component implementation (This is YUI's date widget, not RSF's). The behaviour may have changed in a more recent release of the widget, in which case we may be able to upgrade at some point in the future. However, a general movement *is* over towards the use of CDNs (Content Distribution Networks) for rapid serving of static content from dedicated servers - Fluid is looking towards applying this method for some of its more bulky libraries such as TinyMCE and FCKEditor. So it may become more difficult in future to ensure that every file references is served from a local server. Can you explain why the behaviour is problematic for you?
Cheers,
Antranig.

No need to delete the post... someone may go through just the same mental steps as you, and want to know the answer

The bean which is of the ViewParamsInterceptor type needs to be registered separately with Spring using the "viewParamsInterceptorParent" bean parent class -

Here is a "full" example, you needn't make a definition this complex if your interceptor is at application scope

http://ponder.org.uk/rsf/posts/list/158.page

What I suggest you do is move the information that you require to "switch" on out of the viewID into some other part of the ViewParameters state. Then you can inject two or more producers into the "head" producer that has the common VIEW_ID and then make a decision based on this other part of the ViewParameters, which of the producers to defer to for fillComponents.

http://ponder.org.uk/rsf/posts/list/130.page

If you absolutely require to vary the URL part in which the viewID appears for the different producers, you can write a ViewParamsInterceptor which accepts urls for a "fake" extra viewID that has no template for it, and adjusts the ViewParameters state so that it shifts this information into the "other part" that you set up for the above solution.

Hope this helps,
A.

Yes, the "double injection" is not relevant, and is only as a result of the bean being fired up on the action cycle as I mentioned before. This is not happening on the same cycle but on two successive cycles - this is shown by the fact that it only occurs when a UICommand is involved as I mention. That the properties are "out of scope" also show that this is happening on two successive cycles. Putting them into application scope will lead to a design error, since they will come to be leaked across all requests to your page from all users

Since you have the custom ActionResultInterceptor set up, you now simply need to transfer the relevant state out into the "resultingView" state inside the ARIResult member. This is the only way to transfer state between views - since RSF maintains no session state unless explicitly asked, the only route for information between a POST and a successive GET is via the URL state encoded by this member.

Re "double execution" - Producers are sometimes fired up "experimentally" during the action cycle, just to determine whether they have any input into ARI, etc. and in that case you will see the environment of that request, and not the render request.

Yes - this problem is most likely resulting through the separation of the action cycle and the subsequent render cycle. In all of this discussion, I am assuming that your search is being performed by a POST request rather than a GET - otherwise the answer is a lot more simple.
In general, if you want to propagate "extraneous" state from out of a POST cycle into the following navigation state, you had best use the ActionResultInterceptor infrastructure -

http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=ActionResultInterceptor

Note that a similar effect could also be had with ResultingViewBindings.
However in general you will probably not succeed in storing an entire list inside the ViewParameters state, since there is currently only support for serialising primitive values (not collections). You might get around this by performing a custom encoding (perhaps comma-separated, etc.).

Well - "morally", your form has a submission control - I don't think that the "click" solution is particularly heavyweight. To go into the historical details, the purpose of the submission control is to be able to identify *which* form has submitted, so that an appropriate set of messages could be rendered back in the case the submission fails. It is also used to encode the action method you want to be called - since different methods of submitting the form might lead to different required actions.

As I recall, the effect of missing the submission control is not particularly serious, and merely causes a warning that the submitting form could not be identified. Of course, if you also want an action method, this will also be lost - but naturally you would have to encode this in the form somehow, form submission is not magic

I see you have a number of options -
i) click() + as you say, hidden submission control
ii) fetch the name/value pair of the submission control and add it as a hidden input, and remove the control from the form
iii) getCompleteSubmissionBody
iv) Use the OTP/guard pattern to make a form that doesn't require a method binding
v) You could try creating a completely autonomous form on the server-side by the following:

UIForm myForm = UIForm.make(....
myForm.parameters.add(new UIParameter( SubmittedValueEntry.FAST_TRACK_ACTION, "my.method.binding"));

Of course you should not try to add a UICommand with a method binding in the latter case, otherwise there will be a mess.

So many options

Yes, that is fine - another pretty quick method is to use the standard utility in RSF.js "RSF.getCompleteSubmissionBody"

Thanks for attending to this, bobacus. In general, I do feel the correct response to architectural pains like this is to try to "kick the problem upstairs", and try to question whether the requirement for this information in the application design is really real. Very often, an equivalent or better user effect can be achieved by a different design. Azanchetta - can you explain the overall context of this requirement?

Thanks, Lovemore - sorry I couldn't come round to a reply - I did spend some time staring at your binding log, but nothing very obvious occurred to me

I think we resolved this privately by deciding that the proper semantics were to follow a POST explicitly with a GET? If this is still a problem, please could you post back?

Cheers,
Boz.