Did you mean this?
http://marc.theaimsgroup.com/?l=struts-dev&m=107912629301231&w=2

Pretty much.

Especially with a chain-based request processor, implementation will be pretty straightforward, but we would want to come up with a good solid configuration syntax so that people can do what they want.

In an application we've been working on for about nine months now, we have a variation of this in place which is pretty effective, but which may not be suitable for universal use.

Here's what we do. Might as well start getting specific and see how people like it.

At Application Init time, we ingest an XML config file which produces a bunch of "RenderConfig" objects. Each RenderConfig is associated with a "path", and more than one RenderConfig can be associated with each path.

At request time, there is a "PagePrep" command in a struts-chain based RequestProcessor. This command looks at the "path" property of the operative ActionForward (normally the one which was returned from Action.execute(...)) Any RenderConfigs that are found associated with that path are executed in sequence. The command sites between "ExecuteAction" and "TilesPreProcessor" because in our model, the tile name is the key to the RenderConfig.

By "executed", I mean that an instance of the class designated by the RenderConfig's "type" property is created, and the method designated by the RenderConfig's "method" property is executed using reflection.

There is a single argument to the executed method, "RenderContext" RenderContext contains references to the request and the response, and if the RenderConfig object has a "form" property defined, then it also contains a reference to the form, which is looked up using the core Struts mechanisms used by the JSP tags and form population processes, which means that session scoped forms can be used.

Examples of the configuration elements are below. You can see that this allows common functionality (like the 'setupLitTabs' method) to be shared by multiple views. One could argue that Tiles Controllers can provide a bit of this functionality, but I kind of prefer to get all my possible errors out of the way before the HTTP Response is committed, so that I can have a clean error handling situation. In any case, the prime motivation we had for this was to have a way to get an instance of a form for pre-population.

The multiple-render-configs-for-one-path is a relatively new addition, and it is not yet well suited to preparing more than one "output form," because the RenderContext which is passed into the Renderer is shared throughout a request. (I'm not sure that it needs to be, but we also use it in JSP tags, so it was more risky to consider changing its lifecycle than to share it when I knew we had no need for multiple configs with different output forms.)

One could argue that all of this could simply be done using commons-chain, which is probably true, but I still find that commons chain XML syntax a bit too abstract for comfortable hacking. It might be that we should simply work on that, and it might be that I just haven't spent enough time with it.

To focus this discussion, we should probably know the use cases we want to serve. As noted in this message and preceding threads, prefilling forms is one major use case. Another case which was discussed last year, but which hasn't impacted me that much, would be for dealing with locale-specific details. While it didn't have to do with localization, I did use this "page-prep" mechanism for a non-form oriented type of view preparation: the "setupLitTabs" method allows the renderer to inspect the application/session state and substitute an alternate image for a tabbed navigation element so that one of them appears "lit". This also depends on some other homegrown stuff (like a custom JSP tag and a "UI Toolkit") that I wouldn't push into Struts, but having a standard place to integrate things like that might be useful to people.

I hope this might help move the discussion forward; I'm sure one reason this hasn't moved forward sooner is a lack of specifics about how it might be implemented. Here's some stuff for people to shoot down (or endorse...)

Joe


<render path =".group.FilterTemplates" type ="x.y.z.webui.GroupRenderer" method ="prepareFilterTemplates" form ="filterTemplatesForm" scope ="request" />

         <render
                 path       =".group.SelectDealers"
                 type       ="x.y.z.webui.GroupRenderer"
                 method     ="prepareSelectDealers"
                 form       ="dealerSelectionForm"
                 scope      ="request"
                 />

         <render
                 path       =".group.ConfirmPublicationSubmission"
                 type       ="x.y.z.webui.GroupRenderer"
                 method     ="prepareConfirmPublicationSubmission"
                 />

         <render
                 path       =".library.LibraryMain"
                 type       ="x.y.z.webui.LibraryRenderer"
                 method     ="setupLitTabs"
                 />

         <render
                 path       =".library.FilterAds"
                 type       ="x.y.z.webui.LibraryRenderer"
                 method     ="prepareFilterAds"
                 form       ="adLibraryQuery"
                 scope      ="session"
                 />

         <render
                 path       =".NameAndSave"
                 type       ="x.y.z.webui.CommonRenderer"
                 method     ="prepareNameAndSave"
                 form       ="nameAndSaveForm"
                 scope      ="request"
                 />

         <render
                 path       =".NameAndSave"
                 type       ="x.y.z.webui.ConfigureRenderer"
                 method ="setupLitTabs"
                 />


--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana

Reply via email to