webwork-devel Mailing List for WebWork (Page 49)
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel — WebWork development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(316) |
Dec
(117) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(197) |
Feb
(229) |
Mar
(293) |
Apr
(177) |
May
(84) |
Jun
(40) |
Jul
(43) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rickard <ri...@xp...> - 2001-11-29 09:59:46
|
Mike Cannon-Brookes wrote: > This is perhaps a shot in the dark, but on the OSCache lists / emails we > see a lot of people wanting to cache their MVC work - this includes > caching the view (jsp) AND the controller (action). > > Using OSCache one can really only cache the JSP processing portion of > the request. It is possible to cache (via the APIs) the controller > action, but I think I have a better solution. > > Is it possible to create a 'CachingAction'? <snip> Sure, for some readonly cases it would be useful. AFAICT there's no need to change the framework, or even introduce interfaces. This is only a base class with convenience methods, right? /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-29 09:58:33
|
Jason Carreira wrote:
> This is really to skin the cat that ClientServletDispatcher also skins, i.e.
> managing state and not having to send all of the params with each request.
> In this case, don't save the Actions in the session. The
> ClientServletDispatcher lets you keep the Action and use it multiple times,
> just like this does, only in a different presentation type. I haven't looked
> at ClientServletDispatcher except at the high level that you explained it,
> so I don't know what the impact would be... Possibly instead of the
> Sessionable Interface, it could be declarative in the action mapping as to
> whether this particular action alias is saved in the session.
The problem is that the action is instantiated on the client with CSD.
So, you have no way of intercepting it.
This might change in the future so that one may really call
ActionFactory.getAction() even on the client, which would go to the
server and get it (in order to perform prepare() properly). But then
you'd send a lot of state back and forth three times for each action
that is invoked.
I want the actions to be as shortlived and stateless *as possible*.
Are there any problems with having the action save the state in a
session? Remember that it *can* (if it so chooses) store itself into a
session, and then get it and use BeanUtil.copy to perform pretty much
the same thing. The difference is that the framework doesn't have to
know about it, or be changed to accomodate it.
> You've already got the Action, and it's already got the data from the form,
> so why not use it? It also makes development much easier, because instead of
> having to have your Action be session aware and save things into the
> session, the Action itself is persisted in the session and available for the
> next request.
I would perform this by having a generic action that can be used for
these kinds of things instead. I.e. in your action that wants to save
itself it would do:
StateAction state = (StateAction)ActionFactory.getAction(StateAction.class);
state.load(this, changeCount); // Copy stored action into this action
.. do things..
state.store(this); // Store action back into session, and have it
increase changeCount
Then only StateAction would have to be SessionAware. The changeCount is
incremented for each run, so that if double submitting is done the
changeCount in load() is less then what is in the state store (=session)
then the load fails, since another action has already "used" up the
state of that changeCount(/timestamp).
> This makes Actions more reusable, since they aren't tied to
> saving their data out into a session, so for instance, if you have the
> Action being fed all by a huge one page form, you can very easily separate
> this into multiple pages without having to implement the session state
> saving with the wizard object.
Hm.. this might be idealistic since there's often a difference between
non-wizard and wizard mode in terms of process state changes and
awareness. The above should work better, and also be possible to put in
a base class, e.g.:
protected String doExecute()
{
StateAction state = (StateAction)ActionFactory.getAction(StateAction.class);
state.load(this, changeCount);
doWizard();
state.store(this);
}
Something like that. Now all you have to do is implement doWizard(),
which in turn may delegate to methods for each wizard step.
This approach needs to be tested, but IMHO it will solve the same
problem in a better way since it will not make actions themselves
long-lived (which I really really want to avoid. Gut feeling tells me
its the right thing to do).
> This only works with the synchronization I mentioned. Otherwise, you could
> have the setters being called during the execution of the Action from a
> previous request, since it's multithreaded.
Hm.. what if the prepare() method did the check? Then it could barf at
that point.
Also, if the action itself is not longlived, who cares if the setters
are called? Big deal. It's thrown away anyway. :-)
/Rickard
--
Rickard Öberg
|
|
From: Rickard ?b. <ric...@us...> - 2001-11-29 09:39:14
|
Update of /cvsroot/webwork/webwork/src/main/webwork/config In directory usw-pr-cvs1:/tmp/cvs-serv4997 Modified Files: XMLActionConfiguration.java Log Message: Fixed how command aliasing is done |
|
From: Mike Cannon-B. <mi...@at...> - 2001-11-28 22:16:01
|
Hi, This is perhaps a shot in the dark, but on the OSCache lists / emails we see a lot of people wanting to cache their MVC work - this includes caching the view (jsp) AND the controller (action). Using OSCache one can really only cache the JSP processing portion of the request. It is possible to cache (via the APIs) the controller action, but I think I have a better solution. Is it possible to create a 'CachingAction'? Here's my thinking (and in advance, no this doesn't work for all situations!)... - some actions are merely used not to 'do stuff' but to 'retreive stuff' (take for example search results or filtering of some data set) - those actions take in a defined set of parameters, and for combinations of those produce a fixed set of results (ie query=x&start=10) - could we not then create a CachingAction that looks at timing, parameters and the existing cached results before calling doExecute()? (say if the time specified in getCachePeriod() - default 1 hour - has not elapsed, and a request with identical parameters has already run, just spit out the same result without calling doExecute()) I know this is useless for actions that 'do' something (bad terminology ;) - ie actions that alter the DB) but there are a few situations where I think this would come in handy. Thoughts? Am I smoking the caching pipe too much? -mike -- Mike Cannon-Brookes :: mi...@at... Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World |
|
From: Jason C. <jas...@no...> - 2001-11-28 21:36:58
|
> -----Original Message----- > From: Rickard Oberg [mailto:ri...@xp...] > > > Hm.. I'm not sure this is the way you'd want to do it. First of all I > can see problems with this and the ClientServletDispatcher, where the > action is being sent back and forth between clients and server. Second, > why put the action itself into the session? Why not put a wizard object > representation into the session? It should be simpler to just do that, > and then extract it using a utility class, or a utility action. This is really to skin the cat that ClientServletDispatcher also skins, i.e. managing state and not having to send all of the params with each request. In this case, don't save the Actions in the session. The ClientServletDispatcher lets you keep the Action and use it multiple times, just like this does, only in a different presentation type. I haven't looked at ClientServletDispatcher except at the high level that you explained it, so I don't know what the impact would be... Possibly instead of the Sessionable Interface, it could be declarative in the action mapping as to whether this particular action alias is saved in the session. You've already got the Action, and it's already got the data from the form, so why not use it? It also makes development much easier, because instead of having to have your Action be session aware and save things into the session, the Action itself is persisted in the session and available for the next request. This makes Actions more reusable, since they aren't tied to saving their data out into a session, so for instance, if you have the Action being fed all by a huge one page form, you can very easily separate this into multiple pages without having to implement the session state saving with the wizard object. > > About double-submitting, that should be easily solved by using > timestamps. I.e. in each form you include a number that is increased for > each submit. In the action you compare the number received with the > current number in the wizard object from the session. If its valid, then > go ahead, but if its not, then return an error. That should always work. > This only works with the synchronization I mentioned. Otherwise, you could have the setters being called during the execution of the Action from a previous request, since it's multithreaded. Jason |
|
From: Rickard O. <ri...@xp...> - 2001-11-28 21:23:33
|
Jason Carreira wrote: > I was reading the "Strutting Your Stuff" article in the latest Java > Developers Journal about, of course, Struts, and saw an idea in Struts that > I thought we should steal.... umm, borrow. Basically, the idea was that the > Actions would be saved in the session and reused on the next request. <snip> Hm.. I'm not sure this is the way you'd want to do it. First of all I can see problems with this and the ClientServletDispatcher, where the action is being sent back and forth between clients and server. Second, why put the action itself into the session? Why not put a wizard object representation into the session? It should be simpler to just do that, and then extract it using a utility class, or a utility action. About double-submitting, that should be easily solved by using timestamps. I.e. in each form you include a number that is increased for each submit. In the action you compare the number received with the current number in the wizard object from the session. If its valid, then go ahead, but if its not, then return an error. That should always work. /Rickard -- Rickard Öberg |
|
From: Jason C. <jas...@no...> - 2001-11-28 17:02:58
|
Hi all, I was reading the "Strutting Your Stuff" article in the latest Java Developers Journal about, of course, Struts, and saw an idea in Struts that I thought we should steal.... umm, borrow. Basically, the idea was that the Actions would be saved in the session and reused on the next request. Towards this end, I built a first pass at this. Basically, I created an empty placeholder Interface, webwork.action.Sessionable, that serves as a flag that an Action should be saved and reused in the Session. I also built an ActionFactoryProxy, SessionActionFactoryProxy, which looks for the Action in a map saved in the session map keyed on the name passed to the getActionImpl(aName) method. If it finds it, it returns this Action. If not, it gets the action by passing the request down the ActionFactoryProxy chain. If the Action it gets from the next Proxy implements Sessionable, then it saves it in the map in the session for next time. I thought this could be very useful, especially for things like multi-page forms, so instead of passing all of the variables every time, they're just there, in the Action, when it's activated the next time. It would also save your current position in the workflow (because the command property would also be saved). One potential gotcha would be multiple hits from the same browser at the same time to the same Action. Not an extremely likely case, but possible, especially if your Action takes some time to run, and your users like to hit refresh. I suppose you could control this by making all of your setters and doXXX methods synchronized, so setters and doXXX methods couldn't be called at the same time, and no two doXXX methods could be called at the same time. Anyway, let me know if there's interest, and I'll submit this change. Later, Jason Carreira -- Jason Carreira Lead Systems Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: jas...@no... |
|
From: Markus H. <ma...@ac...> - 2001-11-27 21:48:31
|
On Tue, Nov 27, 2001 at 08:43:50PM +0100, Rickard =D6berg wrote: > I use a mail filter in my email program to deal with this. It sounds=20 > like you want them to separate mail boxes, correct? Otherwise there=20 > would be no difference. Yes, separate mailboxes was what I meant. I filter the mail locally now. Just wanted to hear if anyone else thought a split would be good. Markus --=20 Markus Holmberg ma...@ac... |
|
From: Rickard <ri...@xp...> - 2001-11-27 20:55:33
|
Markus Holmberg wrote: > As far as I can understand, the current XMLActionConfiguration only > adds command aliases to the mappings if the command alias has child > views. > > Isn't the intention that the command aliases should be added > regardless of the existence of child views? > > I have attached a patch to remedy this, assuming it is something that > should be remedied. Fixed, although I added that the alias had to be defined in the first place in order to be added to the mappings. > On a sidenote, I would prefer to have the CVS commit logs mailed to a > separate list (webwork-cvs maybe?). They are definitely useful for > tracking development, but IMHO it would be more convenient to have > them on a separate list. Well, you can't name a list webwork-cvs (SourceForge limitation, webwork-cvs-list would work), but other than that, I prefer to have it to dev since then you know that all developers will see the messages. No complaining about "I didn't see that change!". Why would it be more convenient to have a separate list? /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-27 20:43:57
|
Markus Holmberg wrote: > On Tue, Nov 27, 2001 at 04:28:46PM +0100, Rickard Öberg wrote: > >>Well, you can't name a list webwork-cvs (SourceForge limitation, >>webwork-cvs-list would work), but other than that, I prefer to have it >>to dev since then you know that all developers will see the messages. No >>complaining about "I didn't see that change!". Why would it be more >>convenient to have a separate list? >> > > The intentions are all good, I got no problem with that. > > My motivation is that I'd like to separate mail traffic that is > automatically generated and can come in larger volumes (cvs commit logs) > and human generated mail. (Although I find the cvs commit log messages > useful, I have a low interest in them compared to human generated messages > and hence would like to separate them). I use a mail filter in my email program to deal with this. It sounds like you want them to separate mail boxes, correct? Otherwise there would be no difference. /Rickard -- Rickard Öberg |
|
From: Markus H. <ma...@ac...> - 2001-11-27 19:38:47
|
On Tue, Nov 27, 2001 at 04:28:46PM +0100, Rickard =D6berg wrote: > Well, you can't name a list webwork-cvs (SourceForge limitation,=20 > webwork-cvs-list would work), but other than that, I prefer to have it=20 > to dev since then you know that all developers will see the messages. N= o=20 > complaining about "I didn't see that change!". Why would it be more=20 > convenient to have a separate list? The intentions are all good, I got no problem with that. My motivation is that I'd like to separate mail traffic that is automatically generated and can come in larger volumes (cvs commit logs) and human generated mail. (Although I find the cvs commit log messages useful, I have a low interest in them compared to human generated message= s and hence would like to separate them). But this is not a big issue for me. I can always do this locally with procmail. Markus --=20 Markus Holmberg ma...@ac... |
|
From: Markus H. <ma...@ac...> - 2001-11-27 15:11:36
|
On a sidenote, I would prefer to have the CVS commit logs mailed to a separate list (webwork-cvs maybe?). They are definitely useful for tracking development, but IMHO it would be more convenient to have them on a separate list. Regards, Markus. -- Markus Holmberg ma...@ac... |
|
From: Rickard ?b. <ric...@us...> - 2001-11-27 13:29:21
|
Update of /cvsroot/webwork/webwork/src/resources/web In directory usw-pr-cvs1:/tmp/cvs-serv4418 Modified Files: text.jsp Log Message: Fixed tag error |
|
From: Rickard ?b. <ric...@us...> - 2001-11-27 13:27:38
|
Update of /cvsroot/webwork/webwork/src/main/webwork/taglib In directory usw-pr-cvs1:/tmp/cvs-serv4048 Modified Files: IteratorTag.java Log Message: Fixed status resetting |
|
From: Rickard <ri...@xp...> - 2001-11-26 07:37:39
|
Mike Cannon-Brookes wrote:
> I've written a minor patch to allow users to configure logging
> themselves.
>
> Basically instead of :
>
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties"));
>
> in ServletDispatcher - allow the user to set two init parameters
> (mutually exclusive) - log4j-xml-config and log4j-properties-config
>
> if (config.getInitParameter("log4j-xml-config") != null)
> DOMConfigurator.configure(classLoader.getResource(config.getInitParameter("log4j-xml-config"));
>
> else if (config.getInitParameter("log4j-properties-config") != null)
> PropertyConfigurator.configure(classLoader.getResource(config.getInitParameter("log4j-properties-config"));
>
> else
> PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties"));
Why did you choose to use servlet config, when there is already a
Configuration API that can be used? Seems logical to configure this
through that instead. Otherwise, sure, absolutely.
/Rickard
--
Rickard Öberg
|
|
From: Mike Cannon-B. <mi...@at...> - 2001-11-26 01:10:19
|
Guys,
I've written a minor patch to allow users to configure logging
themselves.
Basically instead of :
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties"));
in ServletDispatcher - allow the user to set two init parameters
(mutually exclusive) - log4j-xml-config and log4j-properties-config
if (config.getInitParameter("log4j-xml-config") != null)
DOMConfigurator.configure(classLoader.getResource(config.getInitParameter("log4j-xml-config"));
else if (config.getInitParameter("log4j-properties-config") != null)
PropertyConfigurator.configure(classLoader.getResource(config.getInitParameter("log4j-properties-config"));
else
PropertyConfigurator.configure(classLoader.getResource("webwork/log4j.properties"));
This allows for more flexibility (optionitis!) without making it any
more complex if you want it simple - sticking with the WW philosophy of
having a default config that suits most users, but configurable if
needed.
Alternatively there could be a LoggingServletDispatcher (subclass of the
original), or potentially just split the log4j configuration into it's
own method which can be overridden to allow you to do configureAndWatch
etc.
thoughts?
Mike
--
Mike Cannon-Brookes :: mi...@at...
Atlassian :: http://www.atlassian.com
Supporting YOUR J2EE World
|
|
From: matt b. <ba...@us...> - 2001-11-24 13:35:20
|
Update of /cvsroot/webwork/webwork/src/docs In directory usw-pr-cvs1:/tmp/cvs-serv22246 Modified Files: action.xml api.xml baseclasses.xml community.xml errors.xml faq.xml features.xml forms.xml hmvc.xml i18n.xml index.xml install.xml intellij.xml introduction.xml jsp.xml license.xml model12.xml validation.xml valuestack.xml velocity.xml wizards.xml xslt.xml Added Files: expr.xml Log Message: add expression language section and id's for chapter and sections |
|
From: Maurice C. P. <mau...@us...> - 2001-11-24 13:15:13
|
Update of /cvsroot/webwork/webwork/src/docs In directory usw-pr-cvs1:/tmp/cvs-serv18908 Modified Files: jsp.xml Log Message: removed my name from ownership of this doc |
|
From: Rickard <ri...@xp...> - 2001-11-23 16:31:34
|
Bordet, Simone wrote: > OT, but what do you use to write docs with docbook ? Notepad ? An XML > editor ? Suggestions from anyone ? I'm in IntelliJ land all the way 8-) Live Templates for IntelliJ are in /etc BTW... /Rickard -- Rickard Öberg |
|
From: Philipp M. <me...@o-...> - 2001-11-23 16:29:51
|
On Fri, Nov 23, 2001 at 04:22:26PM -0000, Bordet, Simone wrote: > > The final missing piece is the docs.=20 >=20 > OT, but what do you use to write docs with docbook ? Notepad ? An XML > editor ? Suggestions from anyone ? XEmacs with psqml-mode.=20 Let the flame war begin! -billy. --=20 Philipp Meier o-matic GmbH Gesch=E4ftsf=FChrer Pfarrer-Wei=DF-Weg 16-18 Tel.: +49-(0)700-66284236 89077 Ulm |
|
From: Bordet, S. <Sim...@co...> - 2001-11-23 16:23:34
|
Hi Rickard, [snip] >=20 > The final missing piece is the docs.=20 OT, but what do you use to write docs with docbook ? Notepad ? An XML editor ? Suggestions from anyone ? > After that, it's game=20 > over. WW will=20 > rule the world :-) Definitely. Cheers Simon |
|
From: Matt B. <ma...@sm...> - 2001-11-23 14:44:45
|
I added the ability to make certain UI controls DISABLED or READONLY where appropriate. The effected controls are: DISABLE: - radio - textarea - select - combobox - password - textfield - checkbox READONLY: - textarea - password - textfield I also added a text page on the index page named "Form test 2". It mimics the "Form test" but disables all the controls. Matt |
|
From: Rickard <ri...@xp...> - 2001-11-23 14:43:35
|
All, I have now released WebWork RC3 on SourceForge. It should be available for download shortly (it takes awhile before it shows up). Highlights of this release from RC2 include: * JDOM support * Updated docs * ActionFormSupport has been deprecated! Only one baseclass to worry about * Now uses log4j as logging API * view mappings are now more hierarchical and allow defaults to be used * iterator tag now exports a status object * i18n bundle selection tag for JSP * "sort" iterator filter tag that can sort your iterators. Standard sorters are included, but you can write your own too. * UI JSP tags can now get values from one place and use another name as field name. * command driven support, allowing your actions to have multiple execution paths * Loads of bug fixes All in all, a great release :-) I hope you will find it as useful as I do. I'm very happy with how WebWork is progressing, and it is becoming a very powerful framework without necessarily being overcomplicated (yet ;-). The final missing piece is the docs. After that, it's game over. WW will rule the world :-) Have fun, Rickard -- Rickard Öberg |
|
From: matt b. <ba...@us...> - 2001-11-23 14:39:43
|
Update of /cvsroot/webwork/webwork/src/resources/web/WEB-INF/classes In directory usw-pr-cvs1:/tmp/cvs-serv7730 Modified Files: views.properties Log Message: added form-disabled mapping |
|
From: matt b. <ba...@us...> - 2001-11-23 14:38:23
|
Update of /cvsroot/webwork/webwork/src/resources/web In directory usw-pr-cvs1:/tmp/cvs-serv7246 Modified Files: index.jsp Log Message: added link to test disabled/readonly controls |
34982 messages has been excluded from this view by a project administrator.
