RSF Discussions Forum

Hi Wilhelm - I am sorry I have let this thread lie for so long, but sometimes I do not get proper notifications of new messages for some reason. I am hurrying out of the office now, but my very first thought is that the use of a UICommand for a "cancel" action is not really idiomatic, since this should almost always never correspond to a non-idempotent server action. The general RSF recommendation is to simply "navigate away" during a cancel operation using a UILink.

The other point you mention, the lack of symmetry between "account.new 1.enddate" and "account.1.enddate" is worrying. My first idea about this is that it could only arise from the natural initialisation semantics on new entities, which are defined in the entity locator itself. It may be that for new entities, this is somehow holding a null or distinguished value, whereas for persistent entities this is always filled in.

It would help to diagnose the issue that in the case where you get an "undefined" value in the UI for the date picker you could paste the values of any XML responses that are received from the server to the UVBView, these are fairly easy to pick out of Firebug. Also, in the server logs you should see some sort of relevant traces, if you have enabled framework logging, there is a guide to this on http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=DevelopmentEnvironmentGuide

I will think about this problem further and see if I can come up with any ideas, but any further information you could provide would be helpful.

A.

Thanks for this report, James, I have updated the page. I am a bit tired this evening so will save a lengthy summary of client-side RSF/Fluid vs. server-side till later... the bottom line is that
i) We have ported the core rendering algorithm, component tree and template format to the client side, so that, in practice, the same set of templates may now be used for rendering either on the client or on the server, as a design demands, and
ii) Are working now on porting parts of the RSF binding layer and data model model to the client-side too, to make work in complex data-binding scenarios easier, and potentially to open up the ground for really slick kinds of "data bus" between a cooperating kind of client and server. However, "client-side RSF" should make it easier to write complex applications that are targetted at any kind of server, as well as making it easier to write applications which can be developed and previewed in the filesystem - this carries forward an important goal of "server-side RSF" into this new world of development.

Well - it depends what you mean by "before" - there are 3 complete request cycles here -

i) render - fillComponents for UBBP creates the UICommand and view
ii) action - the processActionRenew is serviced on the coming POST cycle, which then redirects to
iii) render - fillComponents again for UBBP would show the state updated.

Given that fillComponents will never even execute on the same HTTP request cycle as processActionRenew, you should never see these executing in an "unexpected" order. I am at a bit of a loss to guess what might be happening here, but it would be productive to look at the sequence at the HTTP level - if you open up the views in Firebug, do you see the client redirect occuring as you expect? Is there perhaps some unusual item on the page which is generating an extra request to the server?

Some general observations, although you didn't ask for them

i) navigation back to the current view is actually the default, so you can leave out the two renewed NavigationCases
ii) You only need report the correct type of ViewParameters, so you can just return new SortViewParameters() from getViewParameters
iii) For the renew-item-id, it is not necessary to fabricate your own hidden inputs in the markup directly - RSF will do it for you, if you just add a UIELBinding to the overall UIForm or UICommand.
iv) for "comments:" it isn't necessary to go to all the trouble of making a UIBranchContainer. If you really want two tags when it is shown, and none without, you can just issue the plain UIVerbatim on the server, apply rsf:id="comment" on the <div> and an rsf:id="payload-component" on the <span>.

Hopefully we can make some progress with your real issue though

Hi Zach. The bean override is in theory fine, as an override, but isn't suitable to achieve the effect you want - Java doesn't really treat URLs and files as fully interchangeable for getting stream data, since all sorts of mechanisms are handled differently, down to security considerations, protocol issues, metadata etc.
In order to achieve what you want, you need to target the bean "viewTemplateResolver" which is the one actually responsible for resolving template names onto templates, and in particular it has a subsidiary bean "resourceLoader" as follows:

Code:

   <bean id="resourceLoader"
     class="uk.org.ponder.springutil.ExtraContextResourceLoader" />

(from rsf-config.xml)
which has a simple signature you are wanting - it is actually a standard Spring ResourceLoader. What you will want to do is put an implementation of HttpClient behind this interface since the builtin JDK client is really pretty poor. Good luck, please post back with any further questions or experiences.

Hi there Jim. You should not attempt to take control of the checkbox markup directly, but simply supply the correct initial value to the UISelect control to which they are bound - that is, the "value" of the control should hold a String[] which corresponds to the set of options which are selected.

Hi there - thanks for this report, Wilhelm. It looks like this is a bug which I have JIRAed for the next release - https://bugs.caret.cam.ac.uk/browse/RSF-133 . It should be the job of the framework to ensure that wildcard paths are properly concretised during the invocation phase. I can't really suggest much you can do to alleviate this problem until the next release other than what you have done - apologies, A.

Hi there Jim - have you made sure you are using the 0.7.4 RSF JAR set? What you have written there looks exactly what is required to make this work. And we have test cases

Can you supply the relevant section of your Producer, and also paste in the markup which RSF generates in your page?
Cheers,
A.

Hi there Branden, yes, I think this is a case for which UIVerbatim is just fine.

Cheers for the success story Krishnas - note that this can be actually even easier to accomplish by simply filling out the "consumerInfo" record which is held in the requestContext at the name "consumerInfo" of type
uk.org.ponder.webapputil.ConsumerInfo. This is specially reserved for integration with "unusual hosting environments" such as the reverse proxy one you mention.
You don't mention what the "other" environment is you are dealing with - if you are in Sakai, the default Sakai request parser takes control of the ConsumerInfo structure, and so fitting in at the BaseUrlProvider level as you have is most likely the most direct route.
Yes, I think one of the great strengths is to allow flexibility to deal with situations the framework designer has not directly anticipated. With a "traditionally oriented framework" you are stuck with only easily being able to handle the kinds of environment for which support has been explicitly baked in.

Thanks, the Ryan Lowe. Good to see that RSF is expanding to new frontiers

I look forward to hearing reports and impressions of the framework, and things we can make easy to use. The bulk of RSF framework development these couple of months has been on the client-side - I am glad to report that the RSF/Fluid renderer, the port of RSF's template rendering (and now, a good portion of its data binding) into Javascript, is ready to be presented to the world - there is now an authoritative bulk of test cases demonstrating the complete set of relevant RSF components rendering in all the major browsers - as well as support for I18N on the client (full support for Java-style .properties files as well as JSON forms).

http://wiki.fluidproject.org/display/fluid/Fluid+Renderer

Expect more documentation and a "sneak peek" as part of the framework at month end

Thanks for the reports,
Cheers,
A.

Hi Zack - effecting this change should simply require a change to HTML. All of RSF is predicated on markup-driven control

Simply drop a replacement template with the lists swapped in position into the correct location into your webapp, and the standard Maven 2 build process will ensure it takes priority over the one from RSFComponents.

Hi Lovenalube. This problem seems perplexing, since the injection you wish to do via AJAX could only occur well *after* document.ready - since the AJAX call must occur asynchonously. Trying to initialise in document.ready itself would seem impossible since the markup would not be present. Could you be more specific about the strategy you would like to follow?

An important thing to consider is whether the target textarea is *above* or *below* the script initialisation block you have written there. <script defer = "1"> in theory should evade this issue, but there may well be in interaction. I can point you towards a couple of useful Javascript utilities which may help us shed some light on this issue, and/or get more control over the exact point when the Javascript initialisation block executes. To start with, I am a little surprised that it is executing at all even under IE7 since one usuall needs to go to some explicit lengths to caused init blocks written in AHAH markup to execute - the file rsf.js included in the RSFComponents package contains a definition of

RSF.evaluateScripts = function (parentNode) {

which will explicitly evaluate the contents of the <script> blocks in a particular block of markup. And on the other hand, https://source.fluidproject.org/svn/fluid/components/trunk/src/webapp/fluid-components/js/fluid/FluidDOMUtilities.js contains a "cleanseScripts" function which you may be able to adapt to "set aside" any script blocks you can find, in order to evaluate them later at a controlled time.

I think the first thing to check is the document ordering (above/below).

Cheers,
A.

Hi there - this is the generic message you receive from Sakai when a tool is not properly installed. There can be a number of reasons for this, for which it is best to consult the Sakai documentation. My best guess from what you have said is that you have tried to install a "plain webapp" into Sakai, rather than a specialised Sakai tool. Sakai does not support the deployment of standard webapps as tools, and RSF can be configured to either be registered as a standard webapp or as a Sakai tool. Make sure you have selected the correct version of the sample - this can be determined by looking in the web.xml file to see if you see a registration for the Sakai context listener, filter, and ReasonableSakaiServlet for RSF.

You may also get some log messages during startup of your tool explaning what is happening.

OK, well what is going on here is that the "aggregation" is happening on the server for this particular pair of participants. I think what is confusing you is the recursive nature of the relations - here, "layout" is playing the role of the top-level recipient of the markup, which is, for example, what is sent out using the helper, or, in this case, a JSR-168 Portlet, and "recipe" is playing the role of a *server*-aggregated bit of "sub-markup", which in your cases might be representative of some kind of sub-component like FCKEdit or whatever, which demands some form of Javascript dependency which cannot be expected to be known statically by the overall producer.

So it is not the layout->recipe aggregation relationship which is the model for your "top level page"->"helper" model, but actually the layout itself which would take the role of the helper template in your situation.

I hope this helps a little - sorry there is no very strong documentation on the SCR system but I don't think overall it is particularly relevant here, since a "StaticComponentRenderer" is just the name for a generalised kind of rule which transforms markup, in the absence of a particular component in the component tree. These things can do practically anything, from rewriting a URL to inferring an id. I think it is the particular nature of the head-collect, contribute-script and contribute-style set that we are interested in here. Probably the best thing is to keep on asking questions

The script tags are not written in the (root) template, but they are synthesised (actually simply aggregated) by RSF and injected into the final markup. It is one of the few cases where RSF will directly intervene and write some markup which was not directly present already (or rather, which was not present in the same place - all it is really doing is aggregating the <script> tags from the subcomponent templates which were previously marked with scr=contribute-script or scr=contribute-style into the overall output document).