Page Preparation/ViewController/etc (Re: DO NOT REPLY [Bug 31365] - Add initValue attribute to html:radio tags)
Did you mean this? http://marc.theaimsgroup.com/?l=struts-devm=107912629301231w=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 /
Re: COMMITTERS - READ THIS [was: Re: DO NOT REPLY [Bug 31394] - contributor extensions link on struts main page does not work]
That's cool. I just reported what I saw. It seemed a bit strange to me at the time also, but thought I would just drop a note. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 27, 2004 4:13 PM Subject: Re: COMMITTERS - READ THIS [was: Re: DO NOT REPLY [Bug 31394] - contributor extensions link on struts main page does not work] Hmm. I was able to move 'faqs' and 'images' just now. -- Martin Cooper On Mon, 27 Sep 2004 12:46:29 -0400, James Mitchell [EMAIL PROTECTED] wrote: Permission denied. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Steve Raeburn [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 12:46 AM Subject: RE: COMMITTERS - READ THIS [was: Re: DO NOT REPLY [Bug 31394] - contributor extensions link on struts main page does not work] Ok, I'm confused. Those dirs have group write permission so you should be able to do what you need with them. Also, they have the same permissions as some of the dirs you did manage to move. What error did you see when you tried to move them? Stev -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: September 25, 2004 10:48 AM To: Struts Developers List Subject: RE: COMMITTERS - READ THIS [was: Re: DO NOT REPLY [Bug 31394] - contributor extensions link on struts main page does not work] James, the 'not able' stuff has my name against it, so I probably missed setting the permissions on those. I'll check that out over the weekend. Steve -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: September 24, 2004 7:11 AM To: Struts Developers List Subject: COMMITTERS - READ THIS [was: Re: DO NOT REPLY [Bug 31394] - contributor extensions link on struts main page does not work] I just refreshed, rebuilt, and republished the web site. In doing so there seemed to be some old stuff hanging around under /www/struts.apache.org so instead of overwriting everything, I moved everything I thought was old to /www/struts.apache.org/back/ I did _not_ move the following (either because I couldn't, or it is needed and not part of cvs): ll total 4896 -rw-rw-r-- 1 root struts 45 Jul 3 02:25 .htaccess-- duh! drwxr-xr-x 14 jmitchell struts 1024 Sep 24 06:50 back -- backed up here -rwxrwxr-x 1 jmitchell struts 236 Aug 30 11:43 binindex.cgi -- not in cvs -rwxrwxr-x 1 martinc struts 236 Oct 27 2002 download.cgi -- not in cvs drwxrwxr-x 2 sraeburn struts 512 Sep 12 19:43 faqs -- not able to mv drwxrwxr-x 4 sraeburn struts 512 Sep 12 19:43 images -- not able to mv drwxr-xr-x 5 apmailstruts 512 Mar 26 16:02 mail -- duh! -rwxrwxr-x 1 jmitchell struts 236 Aug 30 12:45 sourceindex.cgi -- not in cvs unzip site.zip Archive: site.zip inflating: proposals/release-plan-1.0.1.html inflating: proposals/release-plan-1.0b1.html inflating: proposals/release-plan-1.1.html inflating: proposals/release-plan-1.1b1.html inflating: proposals/release-plan-1.1b2.html inflating: proposals/release-plan-1.1b3.html inflating: proposals/release-plan-1.1rc1.html inflating: proposals/release-plan-1.1rc2.html ... ... So, that said, if you find you are missing anything you want to keep on the site, please mv it back down. Here's what was moved: ll back/ total 2852 drwxrwxr-x 2 sraeburn struts 512 Sep 24 06:47 CVS drwxrwxr-x 2 jmitchell struts 512 Sep 24 06:47 META-INF drwxrwxr-x 4 sraeburn struts 512 Sep 24 06:48 WEB-INF -rw-rw-r-- 1 martincstruts 7158 Sep 19 20:57 acquiring.html -rw-rw-r-- 1 martincstruts18249 Sep 20 10:42 announce.html drwxrwxr-x 4 sraeburn struts 512 Sep 24 06:48 api drwxrwxr-x 3 sraeburn struts 512 Sep 24 06:48 api-1.0 -rw-rw-r-- 1 martincstruts13544 Sep 12 17:35 bylaws.html -rw-rw-r-- 1 sraeburn struts 4929 Apr 6 16:32 communication.html -rw-rw-r-- 1 sraeburn struts 7451 Apr 6 16:32 decisions.html drwxrwxr-x 8 sraeburn struts 1536 Sep 24 06:49 doc-1.0.2 -rw-r--r-- 1 niallp struts 2621325 Sep 2 05:45 docs.zip drwxrwxr-x 4 husted struts 512 Sep 24 06:49 documentation -rw-rw-r-- 1 martincstruts 9190 Sep 19 20:48 download.html drwxrwxr-x 2 sraeburn struts 512 Sep 24 06:49 dtds -rw-rw-r-- 1 sraeburn struts
DownloadAction Sampl App Sample Going... Going...
Has anyone that needs to downloaded the DownloadAction Sample App I put together? I need to clear some space on my server, and that's a good candidate for deletion. If anyone still needs it, the address is: http://www.omnytex.com/downloadapp.zip Also, I didn't get any feedback on it, so do I assume it looked good to everyone? Or do I assume everyone has just been too busy to look at it? Being as I'm susprised I found the time to do it myself, perhaps the later is the more likely :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] CVS to Subversion Conversion Wednesday
If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) So, are we planning to keep all the existing tags and branches, or do selective pruning? Unless the SVN equivalent of cvs log maintains the entire history on all affected files, I'm -1 on pruning anything unless the infrastructure team says we're being too demanding on disk space. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Don Craig McClanahan wrote: On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) So, are we planning to keep all the existing tags and branches, or do selective pruning? Unless the SVN equivalent of cvs log maintains the entire history on all affected files, I'm -1 on pruning anything unless the infrastructure team says we're being too demanding on disk space. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) My questions have been resolved to my satisfaction, so +1 from me. I assume you'll ask that the CVS repo be frozen at the same time. We should probably say that no CVS commits should happen after Tuesday, to make sure nothing gets lost. -- Martin Cooper Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Martin Cooper wrote: On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) My questions have been resolved to my satisfaction, so +1 from me. I assume you'll ask that the CVS repo be frozen at the same time. We should probably say that no CVS commits should happen after Tuesday, to make sure nothing gets lost. Yes, the freezing of CVS will occur before the conversion by the infrastructure team. They will ensure no commit gets lost. Don -- Martin Cooper Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Mon, 27 Sep 2004 22:10:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Ah, so ... in that case +1. As Martin suggests, I presume we'll want to freeze the CVS version of the repository at the start of the process. Don Craig (who is also updating all his local copies of the CVS repository :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
I'll also take this opportunity to remind everyone who hasn't set their subversion password to do so: http://www.apache.org/dev/cvs2svn.html (step 10). 10. Users who haven't used Subversion before need to log into minotaur.apache.org and run the svnpasswd utility to set their Subversion password. Don Craig McClanahan wrote: On Mon, 27 Sep 2004 22:10:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Ah, so ... in that case +1. As Martin suggests, I presume we'll want to freeze the CVS version of the repository at the start of the process. Don Craig (who is also updating all his local copies of the CVS repository :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
