Re: DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags

[Hubert Rabago <hr...@gmail.com>]

On 27 Sep 2004 16:24:33 -0000, bugzilla@apache.org <bu...@apache.org> wrote:
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=31365>.
> 
> Add initValue attribute to html:radio tags
> 
> ------- Additional Comments From Joe@Germuska.com  2004-09-27 16:24 -------
<snip/> 
> Where Ricardo indicates that creating and populating the form before sending the user to the view is
> "duplicating the work of the Struts Framework," I'd say that we should be making it straightforward to
> do this step.  It's a very common issue and users shouldn't be required to re-solve it.
> 
> I've talked about this on the lists a lot before.  
<snip/> 

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

(My sending this link is a way to test if people wanted to revive the
discussion.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Page Preparation/ViewController/etc (Re: DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags)

[Joe Germuska <Jo...@Germuska.com>]

>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            
Joe@Germuska.com  
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