RSF Discussions Forum

Ok, I'm still taking baby steps here and I'm thinking a bit ahead of myself here so please forgive me if this is a dumb question.

If someone wanted to write a library of widgets to handle things like wysiwyg editors and the like, how would be the best way of doing so?

extending something like uk.org.ponder.rsf.components.UIComponent?

Howdy Josh! Great to see some action in some of the other forums

Here's some words about RSF components -

The RSF "component" model isn't quite like the one in other frameworks, since the hierarchy starting at UIComponent is extremely "concrete", and really exists only to support different model binding behaviours (of which there isn't a lot of variation possible - you can Input or Output things of "UI type" Boolean, String or list of Strings - or for HTML, also URLs). For anything which isn't "different" in this way you probably don't want to make a new UIComponent at all - the wiki page on Component explains the situation a bit. What you really want to do is string together a set of more primitive RSF UIComponents.

The "real" way to write widgets in RSF is by paired sets of ViewProducers and blocks of HTML template. This way you have cleanly separated out into two pieces, code and HTML, what used to be fused in one nasty lump in taglibs.

ViewProducer docs here: http://rsf.fluidproject.org/wiki/Wiki.jsp?page=ComponentProducer

The main caveat is that until we have 0.7 (which I'll start on when I get back from Vancouver), all the HTML rendered in a single view must be present in the same HTML template file.

So while you can get developing stuff like wysiwyg editor widgets right now, you have to make sure that all the "optional replacements" are rendered out in the template.

Looks to me that a wysiwyg editor essentially is a UIInput, i.e. a thing which produces a single String value - so you wouldn't create a new component for that. I guess they are configurable in some standard ways (?) so you might need a bunch of UIOutputs to render the options.

The point of RSF is to get as much of the bulk of the "component" out into the HTML template, with just some tiny field adjustments done by the renderer. This is quite different even to the other "pure HTML" frameworks (e.g. Facelets, Wicket, Tapestry) in that they expect to have stuff kept "in the back pocket" to stomp over the template with.

Actually I'd need to see the HTML for the various different kinds of editor since I've never actually seen one

Then I could give you some hints as to how to get started with that particular problem.

Cool, that sounds easier/better then what my JSF brainwashed brain was picturing at first.

So, how will external templates be included? Will it strcitly be a template level dependency thus allowing UI folks to go crazy with different 'widgets' without the need for any changes in producers and such? What about bean definitions for all the widgets, if you have a large library of widgets will people using them need to add all the bean definitions for the views they use or do you have something slicker in mind? like just a maven dependency to include the entire library?

When are you trying to have .7 done by?

Lots of Qs

The 0.7 work isn't terribly "hard", just rather fiddly since there are some assumptions built in around the renderers about stuff like all the template data being available in a single XMLLump[]. I actually had made half a start on this before going to Austin with 0.6 but had to back off when I realised about annoyances such like, for example, each template file having potentially it's own base directory and hence an independent path for resolving relative links! But this stuff should be out by, say, August.

External templates will be "very cool" in that they will be "include-free". Again, trashing all existing templating technologies (!), these are "heavy" in that you have to explicitly write "include" statements at the head of a file that might want to bring in certain template material ahead of time - which means of course it's impossible to change your mind at runtime.

From the *users* of multi-file templates, very little will change - you'll notice in RSF today there is a BasicTemplateResolver, generally a request-scope bean that works out for the current view which template to use. The only different in 0.7 is that this has the capability to return multiple templates rather than one, with the first one in the list being considered the "root template" at which rendering begins, and the others being "optional branches" that *might* contain targets for IKAT branching. Given the IKAT algorithm is completely "implicit" you never actually need to WRITE links from one template to another, just rendering will perform the branch if there "happen to be" good template matches for the current component in the other file - and then return to the calling template afterwards.

So in RSF actually it's not even going to be a *template-level* dependency - external templates will actually introduce no dependencies at all, not even on each other

Except of course on the actual String you use for the rsf:id, which is where ALL dependencies in RSF fall on.

So yep, the UI folks can go crazy - and I mean really crazy

I'll be showing off the kinds of amazing changes you can pull just with HTML templates at Vancouver, but you can get a sneak preview at the [url="http://rsf.fluidproject.org/wiki/Wiki.jsp?page=ComponentTest"]
Component Test Demo[/url].

So yes, as far as multiple templates are concerned, it's a matter for the runtime to decide where there might be relevant templates - I can imagine that we would supply a "TemplateResolutionService" within Sakai that kept track of a registry of currently available templates for its standard "widgets".

Now, as far as the producers are concerned, yes, these *do* need to be available as bean definitions, but we would just fold these into SakaiRSF as people defined them - each app would keep their own local copies of these defs to avoid polluting the shared area. SakaiRSF currently includes a "skeleton crew" of Sakai-specific RSF beans to deal with stuff like Sites and SitePages which I can imagine is only set to grow explosively.

If you look at the way RSF is structured, this is all completely transparent - for example the Sakai Hibernate demo is sitting on a stack of *five* layered Spring contexts, where SakaiRSF is number 4. Pulling in all the bean definitions is just a matter of making the reference to its internal Spring file from your web.xml.

If people want to make their own widget libraries, this is just a matter of making a JAR with its Spring stuff inside it, and telling people which position in the stack their context should go at (most likely *after* SakaiRSF, but *before* the user's own files).

Good stuff... Between what I've seen playing with RSF and what you're telling me is come in the near future you're winning me over, but I have more questions (as usual).

My next concern is: if you have a centralized set of widget templates that a 'tool' developer is using, how will they pass things into them, for example I'll take the two most different cases I can think of; html ids and values.

There are many cases where you would need multiple instances of the same widget on the same page (and usually in the same form) .. how will a person give items unique predictable id's?

How would a person get a value into a centrally defined widget whose producer has no concept of what a sylabus, assessment question or blog entry are or where to get the right values for any of the above?

Actually RSF already, deterministally, assigns unique ids to every component it instantiates - take a look at the RSF page on full IDs. This is one of the main successes of the RSF renderer in making pages Javascript-friendly, since it's extremely easy to navigate around the tree of dynamically generated components, which form a kind of hierarchical "file system". Compare this to the idiot system of JSF which essentially assigns them random numbers...

The answer to the other question is that producers that serve a particular function (e.g. producing a syllabus, blog entry &c) will conform to a particular API that the person who specced the function drew up. When I call things "ViewProducers" I'm actually talking about things that implement any kinds of different interfaces, but with the one common feature that they take one argument that is a UIContainer which they fill up with RSF components.

The more advanced answer to your other question is that you can actually even do without these "function specific APIs" in RSF, since it allows not only "traditional Spring" but also request-scope IoC. A request-scope configured producer can simply be written out in a Spring file to accept "any number of additional dependencies" from the environment, and just conform to a plain ComponentProducer interface to its clients. The tradeoff between dependencies-as-arguments and dependencies-as-Spring-deps is a balance of efficiency, flexibility, taste &c. Internally for example the bulk of RSF is written using request-scope IoC, to get the maximum possible flexibility for people who want to reconfigure/replace parts of it, except for some cases that really are utterly performance-critical.

Actually ViewProducers can *well* be the most most performance-critical aspect of an app, which is why the API I provided for them for default has enough arguments that it can usually do something sensible at application-scope. For FlowTalk, for example, which has one ViewProducer running at > 500 lines, with lots of other ones hanging off it (try writing *that* logic in JSPs!!) firing up all of that every request would be a big liability. However, lots of Steve's stuff is at request-scope since sometimes for example he needs results from a previous POST cycle injected in.