RSF Discussions Forum

Is there any documentation floating around for the producers and flow xml schemas? I'm trying to piece things together from the demo apps but am getting generally lost without a reference.

For instance I'm trying to get a replicator table of links to load their data on the next page. But when I try to follow the Hibernate demo and see things like this in the view producer for the next page:

<view-parameters type="entitycentred">
<entity name="SyllabusWeek"/>
</view-parameters>

I'm not sure if I need to change things since I'm not using hibernate. I'm also curious about what other types besides entitycentred there are and what not.

Just looking for a general way to decipher the available options in each of these files.

Thanks!

Very good questions! You're right, now I look the docs on this area are either relatively old [ViewParameters] or nonexistent (serialization - apart from a note in the middle of HibernateCookbook_2). I'll write up a proper FAQ entry and a couple of pages to go with it over the afternoon, but here are some quick answers for you:

i) Producers are serialized by "default serialization" as far as possible - that is the field names correspond DIRECTLY to the field names of the respective components. Polymorphism in the is handled by the "type" attribute (low-level function of the SAXalizer). The value of the "type" attribute is either a fully qualified Java class name, or (if you want to go to the trouble), a "type nickname" which is registered with the ClassNameManager inside PonderUtilCore. The convention for all components it that the type nickname is the lower-cased version of the classname with the "UI" prefix missing.

The central answer for all RSF XML mapping questions is inside the mappings directory https://saffron.caret.cam.ac.uk/svn/projects/RSFUtil/trunk/src/uk/org/ponder/rsf/mappings/
In particular RSFMappingLoader.java is the central point of coordination. If you want to add your own mappings, just drop any class implementing "MappingLoader" into your Spring context and it will be automatically invoked on startup.

ii) The flow definitions (if you are using any) are actually in standard Spring Web Flow format, which you can consult the main SWF site on http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home however note there is only a subset of the features implemented, in particular you may not use any EL expressions in the file. Basically anything which you don't see in the NumberGuess sample is not supported

iii) The most important question is - are you quite sure you want to be using XML-based producers at all? For non-autogenerated apps I would strongly recommend ViewProducers writting in Java (or in your case in Jython

- consult the Java version of the Cookbook app for details https://saffron.caret.cam.ac.uk/svn/projects/RSFHibernateCookbook/trunk/javacategory/, since these will in general be faster and more readable. Also this would free you from having to worry about mapping issues.

iv) The only two ViewParameters implementations in RSF indeed are the EntityCentredViewParameters and the SimpleViewParameters - the idea is that every app will certainly want to implement their own - after all who else would decide on URL structure and state but you? RSF makes it easy for you to have completely different URL structure even on a view-by-view basis - the only fixed part is that the first part of the path-info up to the first slash represents the viewID which is the basic index used by RSF. If you want to add new ViewParameters, just derive from ViewParameters, and implement the abstract methods. If you want you can then register the nickname with the mapping system in a MappingLoader, as in the following sample from RSFMappingLoader:

Code:

   public void loadExtendedMappings(SAXalizerMappingContext context) {
     context.classnamemanager.registerClass("entitycentred", EntityCentredViewParameters.class);

Yes, there is no requirement to be using Hibernate at the same time as EntityCentredViewParameters. The RSF "OTP" system just expects you to have a set of EL paths that do the mapping correctly, which you could implement in any way you like (for example by implementing java.util.Map or BeanLocator).

For example for an entity "SyllabusWeek" you might define a (request-scope) bean called SyllabusWeek that is a Map for which the key is the ID of the week, so that paths of the form

#{SyllabusWeek.syllabusid}

map onto the required object.

I think this is very cool and finally frees us both from the tyranny of DAOs but also from ORM coupling as well as a number of other evils

Hope this helps - and please let me know what if anything is leading you to use XML view producers since I've always been interested in precisely what the use cases are for these (I in general never expected people to write these by hand).

Thanks, this reply was very helpful.

I was using XML Producers mostly because I was following the example apps on the Wiki. I'm just now realizing the potential of using the Java based producers. I really like that I don't need to specify an EL mapping for every single label.

The last 3 days have been a very refreshing experience. I'm still unsure about many things, but the fact that the core of RSF is such a manage-able size makes it reasuring that the daunting tasks will fall down easily.

While we have jython in the thread...

When I get more comfortable I would like to explore the ability to have EL expressions map to Jython modules. Say I have some Jython files in WEB-INF/code and the EL expression #{bean.value}

It would be nice to possibly see behavior as follows:
1. Go through the normal rounds of looking for a Bean mapped to 'bean'.
2. If that fails look for a jython module in WEB-INF/code that is either named bean or somehow mapped to bean and see if it has a property called 'value'. This would be a real interpreted Jython call (ie. you wouldn't have to compile the Jython module ahead of time). So we could take advantage of adding methods at runtime and whatnot.

However, I'm very much enjoying using Java right now with RSF. It's small, compiles fast, and runs fast. This is great stuff.

Steve - glad you're having fun! Fun is what's about... or at the least, the absence of not having fun

Regards your "bean" question - the answer is, "it's all in the bean". Whatever strange resolution behaviour you want for the bean marked "bean" must be in the class you get when you try to load it from the context. So if you want it to optionally load a Jython module when someone tries to get the "value" property, then write one that does this - RSF features the marvellous OLI (one-line-interface) BeanLocator
Code:

 public interface BeanLocator {
   public Object locateBean(String path);
 }

Any bean found implementing this interface (or java.util.Map) will be navigable by EL to the next path segment, which is a nice and cheap way of getting "interesting" behaviour into your bean model.

If you use this approach, you could use the BeanUtil.navigate method to automate the process of reflecting over your Jython bean inside the BeanLocator implementation.

Yet another option is to use Spring AOP to make make your bean "Bean" a proxy for the Jython bean - you would do this by using a Spring LazyInitTargetSource to hold the reference to the "real" bean and fit a Spring ProxyFactoryBean at the path "bean".

BUT - all of this might actually be unnecessary depending on exactly what you want to achieve - since it might all "just work" depending on exactly what kind of "switching" you want to achieve. When you say "go the normal rounds of looking for a Bean mapped to "bean"", what might you be expecting to find there? If all you might ever want to find is your Jython bean, you might just map it there as a Spring FactoryBean and be done with it.

This is all part of the magic capabilities you get from merging Spring with request-scope programming, and might be all you need - give me some more details and/or some sample code and I can help you out.