RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich ==///== Craig R. McClanahan wrote: There's a couple of variations on the theme that are possible, but I can think of at least three layers of something that might be called a form bean in the conceptual sense: (1) A set of typesafe field names and corersponding values where the application doesn't have to worry about maintaining values across requests. - Variation: dynamically add and remove fields as needed - Variation: allow non-typesafe fields - Variation: allow fields that can have multiple values (arrays) - Variation: represent data hierarchically instead of just a name-value map (bean properties, nested expressions, XML DOM, what have you) (2) The above plus a mechanism to define validation rules (correctness checks) on the field values that are independent of physical presentation - Variation: hard coded logic for validations (i.e. the original validate() method in Struts ActionForms. - Variation: pointer to a configured set of validation rules that is abstracted from presentation considerations. (3) All of the above plus event handlers for UI events that change the state of the field values -- perhaps in the same bean, perhaps somewhere else. A type (1) or type (2) form bean is really better thought of as an abstract way to pass the input data for some sort of business transaction between tiers, or within tiers. A type (3) form bean would definitely live in the presentation tier, and not be used between them. For all three of the cases, though, we probably want to invent a different term than form bean because that seems so conceptually tied to presentation only. Transaction Bean? Input Bean? Data Transfer Object :-)? Can't it be just one good old View layer thing that maps the properties and it's still called formBean? KISS Don did not link XMLForms good, here are better links for a real fun read: http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html http://www.cocoonhive.org/xmlform/index.html I like that Pico is lightest IoC and do not see a need for a Bean Factory, etc.. So there should be some talk of Spring vs Pico. So far, if it's built on top of -IoC -with XMLFormBean (as option, since XML can be slow right now, so it needs to support backward compatible FormBean) -an execute(context) Action iterface, -chain request procesor filter interfaces -HTML tag to support XML Submit (including multi row) -JDK 1.4 -Clear testing interface to major user components. That could be the broad stroke major center pieces. It is same design as Struts 0.6 with each component refactored, same diagram. There are several smaller pieces, but if Struts can stay light without too many moving parts, better, people can put arms arround it. XML config wishes: - all xml files be able to extend like tiles, like in Validator - move form beam declaration section to validator, no need to do it 2 times. - move all tiles xml to struts config, and get rid of tiles.xml - have a forward to a tile declaration allow you to name the base definition and tile to replace, even maybe have tile part of * forward or what ever Don's thing is called. This would involve XML namespacing for Struts DTD, but Ted has already addressed, if you want to make gigantic configuration file. I think the simplicity is in the modularity of the XML files rather than having a monolithic mess/. I still kind of think maybe DAO interface should be there, we learned a lot about DAO since. Data Model should be agnostic regarding Struts. (I still think one or 2 people should do it in 48 hours from start else... it's design by comittee) .V Keep in mind that Spring has its own Model View Controller package, and Rod Johnson berates Struts 1.0 a little in his book Expert One on One ... concerning ActionForm themselves. Having spoken with Don Brown, I can see the benefits now of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating a graph of objects from an XML file is pretty handy for certain situations. I can see the light of the joke. Objects just Spring into life from literal paper. I guess the decision here will be political. Can we just take or borrow the org.springframework.beans.* of your framework? Hmmm. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: 17 December 2003 22:11 To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:04 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. I agree with your assessment of frameworks 100%. However, Spring is under an LGPL license, so Struts can't use Spring unless either Struts switches to LGPL or Spring switches to ASF, right? It would be kind of silly for Struts to stay under ASF in this case, since the Spring license would force the undesirable LGPL clauses on any projects that were based on Struts. Am I right? Matt What kind of Spring Framework classes would you want to use in Struts 2.0? The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. The major design difficulties are abstract away the request and response objects from the controller actions, and also configuration of any other front-end objects you need along the way. To a certain extent Commons Chain and its context leads the way regarding the former. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: 17 December 2003 23:00 To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) ==== A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? Legally, I'd say that Strut is whatever the Struts Community says it is. It's a brand that belongs to the ASF, which we manage on the Foundation's behalf. Technically, I'd say that Struts (or any framework) is an aggregation of its components. In Struts 1.0, we had mainly Form, Forward, Mapping, Action, and Messaging components. In Struts 1.1, we added Exception, Validation, Composite (or Tile), and PlugIn components. So long as Struts 2.x retains the same hallmark components in a recognizable form, I'd say it's still Struts. :) Overall, it's my feeling that Struts does all the right things, it's just that we don't do them in all the right places. :) Being able to extend elements is one example. Encapsulating paths is another. My own goal for Struts 2.x is to consistently apply all our best practices and eliminate inconsistent and legacy practices. We've got a good thing here; we just need to make it even better. :) In terms of new functionality, the three biggest fish I'd like to fry are Workflow, SSL, and Unit Testing. Towards that end, I'd like to consider integrating LivingLogic's Workflow, ssl-ext, and Struts TestCase into the Struts 2.x development stream. We may also want to consider adding these as standard options to Struts 1.x, so as to blaze a trail. Integrating StrutsTestCase would help with the Unit tests, although it will have to be heavily modified in parallel to keep up with changes in development. Although it's not evident from the Jericho DTD, the intention is to use a Context object in the signatures, perhaps the Commons Chain Context, so as to encapsulate Servlet/Portlet dependencies. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); And for those of us who have subclassed Action, and ActionForm to create our own super frameworks, this will be very interesting and involved work to say the least/. -Ted. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich In terms of new functionality, the three biggest fish I'd like to fry are Workflow, SSL, and Unit Testing. Towards that end, I'd like to consider integrating LivingLogic's Workflow, ssl-ext, and Struts TestCase into the Struts 2.x development stream. We may also want to consider adding these as standard options to Struts 1.x, so as to blaze a trail. I aqgree that DAO should be outside of Sturts. I do not think Workflow should be inside. Becuase I do not think it is a good practice. It may be needed by some people... as a plug in. Struts greatest strength up to now is its agnostic data model feel. You need to supply the Model architecture, so I agree there. It has also been historically a weakness where users have been a little confused by form bean and data transfer objects. Ie the various ways of streaming information back and forth the tier. Integrating StrutsTestCase would help with the Unit tests, although it will have to be heavily modified in parallel to keep up with changes in development. I also do not think testing should be insdide. There are many that look into JVM, into container's JSP, etc. and people should inovate. I use OpenSTA, becuase I want to see what happens under load. Au contraire. I think it would be benefit the framework if there was a standard Strut's unit test part available out-of-the-box. It would aid developer's writing containerless unit tests, otherwise it is down the road with Cactus. Nope. Strike that StrutsTestCase does support Cactus. Whatever the framework should have unit test of its own delivered whether it is Struts Test Case or self-amogrified hand crafted ``junit.framework.TestCase'' subclass. However... Monitoring and Managing the application while runing in production maybe should be included. Ex: Jamon. I used it, and it's great. I works similar to log4j. Or at least it should be documented. In days of ClientServer, 3 tier ment: Data Layer, Presentation Layer and Managment Layer. You could add this feature on with JMX and MBean and write a ``ComposableRequestProcessor'' , I mean special Command to monitor the processor flow. Perhaps you can write an instrumented `org.apache.commons.chain.Chain implementation' that is JMX compatible. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); Why not just KISS and public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. .V Yes I agree KISS is better, Vic. It is better by the design. Maybe you can be person to announce to the Struts 1.0 1.1 user base that all of their Actions are now invalid, they wont compile for Struts 2.0 because you need to upgrade ALL your state methods to get HttpServletRequest and HttpServletResponse and ActionForm and ActionMapping from the Chains context. This is early days, and too-low level so I 'd put this point on the back burner. It can be easily solved using Java Reflection. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich ==== public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. I was going to add: This lets people store and pass additional info. Else they start putting properties in action (not thread safe). Maybe Struts 2.0 should have an action implemenation that gets instaciated every user session (it should not be used but... it exposes the issue). .V If you look Commons Chain then you will that the ``Context'' (or it at least its concrete implementation ``ContextImpl'') is a `java.util.HashMap' subclass. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [struts chain] Investigating Dynamic / Proxy Commands?
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Personally, I would setup my own catalog for the application that contained all the business commands. The Action then prepares the context, invokes the Command from the Catalog, and extracts the result. I think I am trying crack a nut with a different cruncher. Currently in Expresso Framework we have built action chaining and call it Transitioning. I realise that may be instead of using Struts Actions to do this, we could develop a business command like you say with all the convenience methods and some of the state from the Framework exposed as named command attributes, just like Craig showed. This would allow to form transitioning at amuch lower level than using Actions to do this. This is what I'm during in current development, I just need to put together a generic standard Action, like the ProcessAction from Scaffold (only simpler). One very useful strategy is to name the ActionForm attribute after the corresponding Command. The ActionForm attribute is also the ValdationForm key, which speaks to what input parameters the Command expects. The ducks all line up in a row. name=app.MyActionForm attribute=add_account Action ... form name=add_account ... ActionForm ... command name=add_account ... Command --- The Command is then invoked automagically by using the form attribute name as the command key. For lack of a better name, I've been calling this the symbolic strand pattern. You give the use-case a symbolic name, and then keep using the name between layers, forming a contextual strand through the application. To close the loop, I would have a SQL query called by the Command also named add_account. Otherwise you would have to introduce a special property in the Struts Config that identifies an actual low-level Command. You could do this as well have a mapping of Action to Command. Not sure of the XML syntax of the action-mapping. IMHO, whatever the Action does should either be put into a base class, or into a catalog of business commands that can be used (and tested) separately from the Struts portion of the application. Yes I think I understand. The Struts Action become like wrapper/delegators/executors of the business logic. Obviously and suddenly Actions may shrink a bit to smaller classes. The newer Business Logic Commands then are the ones that communicate with the database tier and the business tier using the service locator or business delegate. Though, I do mean to try giving the Action it's own customizable RequestProcess gauntlet, rather than a base class, but that implementation could use the same techniques we're using now. -Ted. It is almost like an inversion-of-control idiom, but this chaining not IoC. My concerns are the exception handling strategy. It would be a new area of work and experience to deal with flow logic. Trapping and raising exception would be where the bug bears lurks. If one command fails, we would want to know the actual failure point, if the command failure is unrecoverable. If it is recoverable what do you do? Skip it or return regardlessly. We will see indeed. Peter A. Pilgrim wrote: Ted Husted wrote: It might be better to bring this up on Commons Chain, Peter, since these questions seem to transcend our implementation of the Request Processor (aka Struts Chain). -Ted. Peter A. Pilgrim wrote: I am investigating the possibility of commands that can branch dynamically. Why was the ChainBase frozen in the execute() method? What is the design decision or intention of NonDelegatingCommand.java? What do you need to successfully compile and build the chain module? Well I guess what I am really after is a successful action chaining features that works with Commons Chain. I see there are couple of abstract classes: contrib/struts-chain/src/java/org/apache/struts/chain/Abstract SelectAction.java contrib/struts-chain/src/java/org/apache/struts/chain/Abstract ExecuteAction.java To perform the action chain means add two these into a new Chain or creating a new Catalog with these Chains. This is why I wanted to know is Action going to be more a Command, or is it going to stay a seperate entity as it is now the Controller in MVC Model 2. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to
RE: cvs commit: veto
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Craig R. McClanahan wrote: To address Ted's (legitimate) concern, I would prefer that we adopt a more stringent (but one that can be administered based on reasonably objective criteria) policy on Struts website content -- no advertisements of *any* commercial resources related to Struts. Google does a far better job than we could ever do in making such resources available, and this would avoid the need for any judgement calls or unfair advantage to some commercial entities over others. Announcements about nonprofit activities (user group meetings), freely available presentations/demos/slides about Struts, or other open source software that works with Struts, would still be reasonable candidates for inclusion. Note that I'm suggesting this approach just for the website (and therefore the snapshots that get included in the product by virtue of the way we create struts-documentation.war). The current policy towards postings on the mailing lists can remain the same -- the distinction is that it is clear who is speaking (presuming it's not an email virus forging the from address :-), and there is no opportunity for mistakenly assuming endorsement. Implementing this policy would require a few more excisions to the Struts web site (and save Ted some work in the long run, since he does most of the routine update work), but not horrendously large amounts. The most visible change would probably be the list of books on the front page and the associated books.html page, since they are all commercial activities. I agree with Ted on the consultants and powered pages. Ted, would this deal with the criteria of your -1 IMHO, such a proposal would not be in keeping with the business-friendly attitude of the Apache license. It seems inconsistent that we would encourage commercial entities to incorporate our products within their own but then shun mentioning them. If we avoid mentioning commercial success stories then wouldn't you loose the attention, and the awareness of other projects? The more success stories of using Struts the more people are attracted to look and evaluate the project. I would say that Struts has been a wonderful and marvellous success itself. It was the first MVC framework that I understood and the design itself, I thought, was brillaint. It was like what Mr. Steve Jobs (of Apple/NeXTStep) once said, This is insanely great!. That is when I looked at it in July 2001 for an old project that was getting starting at my old work place [Deutsche Bank]. On the horizon, Struts now has some real competition like WebWork2 / XWork by Atlassian. Right now the advantage of WW2 is the idea of chain of responsibility which Craig has started to address with his work. Ok we are not loosing Dollars, Euros, or even Pounds, but what is valuable is the mind share of developers. Loyalty and innovation should go hand-in-hand together with a dash ethics and professionalism. I dont think you should ostracise an individual because of his apparently crazed verbosity. We should answer with a rebuttal or refer the matter to a higher board. We should not respond with avarice and nonsense, because we risk losing the developer base. If we loose either one of them then the risk is that we loose those trusted application users, and what good is framework without loyal users? But, more importantly, in the end, I doubt that such a proposal would meet the thinly disguised goal of punishing a certain individual. For example if an individual were to make a PDF of a book they control freely available, then, under this policy, it may be the only book linked from the Struts resource page. Thus, giving this individual more exposure rather than less. I think we to take time out to reflect just what is going on here. The allegations are abouts copying source code from one project to another. I have only two concerns about going on. 1) All the types of open source license need to be understood. It appears it was not understood. 2) It should be between Apache Software Foundation and JBoss to , those two parties sort out what has gone. An interesting point in history is being made. Where once a software developer was consider good, if he/she wrote smart and clever code, now we are apparently drawing the line underneath the old maxim, a great developer is steals his/her code.. It is first time I have noticed ever that two opensource are fighting a mind-share war. Could it happen between Struts and WebWork, or Barrucada. Ted is quite right about the business friendliness of the Apache. It is what gets the real senior management, the one who have the power and infleunce, the decision makers, behind opensource and to support a decision to use a framework or source code in a project. Even without there being any change in the
RE: [struts-chain] Some ideas
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: 12 November 2003 02:06 To: Struts Developers List Subject: Re: [struts-chain] Some ideas Quoting Konstantin Shaposhnikov [EMAIL PROTECTED]: Thank you for quick response and your ideas about the implementation. But can I ask you why I can't use the second approach with struts 1.1. I explore struts-chain code once again and found that I only need to change 1 Command in servlet-standard chain. You can certainly customize the chain if you want to use it with Struts 1.1, but that means you are playing with unreleased code and having to live with whatever restrictions exist (for instance, file upload is not currently supported in the existing chain definitions). I am imagining a day where we'd build the standard RequestProcessor for Struts 1.2 on top of the chain implementation. That would be best. And what means provided for backwards compatibility with Struts 1.1 ? Will the next release replace Actions with something else? One of the key things people would look for from Struts 1.2 is a relatively easy migration of existing Struts-based apps. Therefore, it would seem best for us to be able to call an app's existing Action classes (as the current struts-chain implementation does). In a future world solely based on chain, you wouldn't need the idea of an Action class at all. Instead, you'd map the action element in struts-config.xml to the name of a chain, which could either be a single Command or a series of Commands -- Struts would not care. In this environment, there would still be a standard set of commands in the standard chain, to do all the standard stuff (like populating a form bean, performing validation, and so on). But the thinking is that the app's business logic would be built out of chains as well, which can (of course) be arbitrarily complex in their internal structure. At the moment Expresso Framework is leveraging off the Struts MVC. Our `Controller' classes are extension of the Struts `Action' class. If the Action class is going I would like to know about it. I may have asked this question before is the `Action' going to be `Command' eventually. Among other things, this would allow people to not have to attempt to use action chaining, which today causes surprising results. Instead, you could build little two-Command chains -- the first would process the form submit, and the second would do the appropriate setup for the next page to be displayed. Because these two behaviors would be separated, you could reuse either or both of them (for example, cases you need to forward to a particular page from more than one place, and perform the same setup behavior each time, could share the second command. When people like myself have been using Action Chaining we have been setting up the second action dynamically. It is kind of a dynamic multiplexing. What Craig has written above describe static chaining, I presume with the XML configuration file. I suppose what I would want is like having a `Command' add the next command to end of the `Catalog' at run-time. I need to really delve into the chain code myself and check if such a thing is possible. Of the top my head, for this scenario, it does not make sense for an `Action' to be a `Command'. Instead a specialised Command should exist that can invoke any `Action' in current `ModuleConfig'. I am sure such a beast already exists anyway. best regards, Konstantin Craig -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: struts application with frames: top, side menus and main scre en
-Original Message- From: neso m [mailto:[EMAIL PROTECTED] Hi ! Has anyone found sample STRUTS application and/or documentation on the net that uses frames. Top menu, side menu and main screen. Could you please respond directly in case you can and willing to help. PLEASE send all framework/application user questions to the STRUTS-USER mailing list. Ok it is not a web site, but you might want to try also the WROX book Professional JSP Site Design by various people. I believe that big red book has a chapter dedicated entirely to HTML frames. It's about a railway site. Thanks ! Nesh Your welcome -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: cvs commit: jakarta-struts/doc/resources archives.xml co nsultants.xml powered.xml sigs.xml
WOW WEE! Politicking on the Struts DEV list. I am definitely ashamed now. Talk about taking the lollipop (for my USA friends, the Candy) out of the babies# mouth. It's definitely a bridge too far. End of the world is neigh impossible to contemplate. After too much mastication that tooth is broken on out ... Need I go on. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 11 November 2003 21:24 To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml craigmcc2003/11/11 13:23:32 Modified:contrib/struts-faces build.xml doc learning.xml using.xml doc/faqs kickstart.xml doc/news news_2001.xml news_2002_q2.xml news_2002_q3.xml news_2002_q4.xml news_2003_q1.xml news_2003_q2.xml news_2003_q3.xml doc/resources archives.xml consultants.xml powered.xml sigs.xml Log: Vic Cekvenich of BaseBeans.com has made it clear in public postings that he is ashamed of using Struts, and has engaged in an attack on the proper behavior of the Apache Software Foundation's Board of Directors. In these circumstances, it would be hypocritical for BaseBeans to benefit from the free advertising value of being visible on the Struts web site. Help them out of this conundrum by removing such references. *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: cvs commit: jakarta-struts/doc/resources archives.xm l co nsultants.xml powered.xml sigs.xml
-Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: 12 November 2003 18:01 To: Struts Developers List Subject: Re: [OT] RE: cvs commit: jakarta-struts/doc/resources archives.xml co nsultants.xml powered.xml sigs.xml On Wed, 12 Nov 2003, PILGRIM, Peter, FM wrote: WOW WEE! Politicking on the Struts DEV list. I fail to see any politics involved. Everyone is free to voice their opinion. Everyone is free to make an ass of themselves. Everyone is free to make an ass of themselves in the most public ways possible. On the serious side. I disagree. This whole argument is about policy and standards of professional practice. Where there is policy there is usefully some politics involved, however much you and I may hate to get into or love to get debated about politics. But when you refuse to listem to reason (or in this case, you refuse to listen to anything), you find yourself paying for your actions. At Apache, you can have your cake and eat it too, but you can't smear it on someone's face (hypothetically speaking) and get away with it. Agreed, all I have done is look up TheServerSide.com and chase up some of the mailing/web lists. It is a lot of nonsense and hyperbole now. The information, real one, has been lost in the ether. Vic: I respect your support for Struts and this community, but dude.you've got to chill out. That goes for everyone. I am definitely ashamed now. Talk about taking the lollipop (for my USA friends, the Candy) out of the babies# mouth. It's definitely a bridge too far. End of the world is neigh impossible to contemplate. After too much mastication that tooth is broken on out ... Craig is probably THE most tolerant person I've seen on this (or any) mailing list. I'm sure he doesn't like having to do these kinds of things, but I will support him nonetheless. I assume you're right, because I have never met Craig in person. To me it looks like Vic is horrendous fast typer, some kind of cant-really-express-himself-appropriately guy. He appears intelligent, and knowledgeable, but over passionate. Yep I agree you need passion [the hard red and black stuff from the sunny country of Spain] to make it in any profession. You've got to believe first to be successful. He sounds like he is fighter for open source, but his communication leaves a lot to be desired. I read he was assumed of Apache Struts as he was ashamed of using it now that these dreadful allegations, as yet unproven [Mr Anderson/Neo] have come out.. I think this slightly different from just I am ashamed of Struts. However, I cant second guess to claim to know the intimate mind of Vik, but I dont know maybe the punishment is slightly harsh. It is amazing the pyschology of the red mist and a person who sits a computer with just keyboard and VDU. You wouldn't believe it, but it is apparently true ;-) Have a very calm evening. Need I go on. ---- -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Eclipse to contribute to Struts
But not lot of text to go with it! -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 06:53 To: Struts Developers List Subject: RE: Using Eclipse to contribute to Struts James' version uses 'Check out As...' rather than 'Check out as Project'. That's probably better as you can set up the classpath and get the code completion feature etc. working more easily. My notes don't cover that at all so use his first. And he has pretty pictures :-) Steve -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 10:33 PM To: 'Struts Developers List' Subject: RE: Using Eclipse to contribute to Struts Here's a little something I put together also: http://www.struts-atlanta.org/helping-develop-struts/index.html -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts-chain Behavior Discussion
-Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] - Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. What are you talking about here? What I am talking about or rather aiming the ability create common Struts components. Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. Ay Ay, Captain! I don't mean to rain on the parade. I was involved in the composable request processor discussion way way back in the summer. As the Expresso core committer who integrated Struts 1.1 I found also a futuristic design issues merging the TilesRequestProcessor and our own ExpressoRequestProcessor. How would you merge the next processor, and the next one, and the next one after that. But the problems have not been cleanly solved in regard to reusability. When a Command is deeply coupled with other Command(s) in a chain through one or more flags/states in Context (say cancel flag, invalid token flag, invalid validation flag, etc.) its reusability in a different chain is very low in theory or very difficult to use (you need to configure many flags to get it work and subject to the condition the new Context offers the same set of flags). I dont understand the reusability problems. To me having read the Gang of Four original book, the design of Chain of Responsibilty and Craig's code and what he has said to me (to us) on list makes this a non-issue. Actual design pattern is a linear path. The only difference I can see is the context, which I guess you should treat it as opaque object any way. If you write a Command that need various context setting that you should declare in the javadoc or documentation. I did a little exercise to reduce the command coupling degree by introducing a NestCommand. Like LookupCommand to execute a specified chain, NestCommand always return false regardless what nested chain returns. So a termination of nested chains does not force a termination of calling chains when NestCommand is used. The following picture illustrates the idea: You said your NestCommand always returns `false' Main Chain: NestCommand Nested Chain: NestedCommand1 NestedCommand2 NestedCommand3 LastCommand If any nested commands return true, the control flow will *jump* to LastCommand. It seems to give an answer to my original question without the notion of branch behavior :-) And this paragraph NestCommand can return true. This conflicts with the first. What if NestCommand return false does that not terminate the chain, and thus stop LastCommand from executing. NestedCommand2 does not need to check any flag set by NestedCommand1 in this way and NestedCommand3 does not need to check any flags set by NestedCommand1 and 2. They could be reused in other chains without concerning about flags. It sounds to me like you trying to create conditional commands. A | B-D-E | C If B is a command that has IF THEN behaviour that is on a boolean flag V then if V == true then the order of execution is A,B,D,E,C (the execution terminates after C) otherwise V == false then order
[test] test
test 1 2 3 4 -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts-chain Behavior Discussion
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: 06 October 2003 17:25 To: Struts Developers List Subject: Re: Struts-chain Behavior Discussion Paul Speed wrote: I haven't looked at the implementation yet (I intend to when I have more than 2 seconds free) but I have been lurking in this discussion. It seems to me that if a command could nest a chain then all things are possible. In fact, you wouldn't even need the jump to last command logic since that step would be part of the master chain. Craig's example might then be like: (1) LookupCommand (2) ExceptionCatcher (3) SelectLocale (4) SelectAction (5) Process Form (a) CreateActionForm (b) PopulateActionForm (c) ValidateActionForm (6) CreateAction (7) ExecuteAction (8) PerformForward I don't know how easy it would be to run a chain from a command, so it may not be feasible. From a processing perspective, it seems clearer to me. Running a command from a chain is trivial. In fact, that's what the ValidateActionForm code (quoted below) already does. In this case, it's done for conditional behavior, but that is not required. You can actually nest chains inside other chains (remember that Chain *extends* Command) for arbitrarily complex straight through processing flows. Yes you multi-dimensional chains of responsibilities. One dimension for default chain, and another axis for a fork. *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Or is the recommendation. Do not make Actions chainable whatsoever, but instead write (chains of modular commands) that are called from singular monolithic Actions? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven is Wicked!
I have been very busy unable to catch with Struts Dev list. Anyway I was fighting with Turbine/JCS trying to compile with Ant, I was literally beating myself up looking at these dependencies, then I read in a forum somewhere Use Maven. I used Maven. Oh my goodness. Whoop! There it is. Why does Struts not a build tool like Maven yet. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Re: ActionForwards, et al (was SuccessAction)
-Original Message- From: Micael [mailto:[EMAIL PROTECTED] Hi, Peter, Yah, there are some that don't like free knowledge or listening. So there was no way to not offend some people. I appreciate that. Why I don't know, and I don't need to know. But, I have a watch. LOL. Micael It would appear to me that your talent for English grammar is not being put to good use. Apparently you did waste your education at college. I dont know if you are idling away in the Struts developer mailing list or if you are now the new ``Mark'' out-of-topic, Friday guy in this list. ( One of the reason why I did not resubscribe to the struts-user list after my holiday, I got really tired of the OT/FRIDAY stuff, but I digress ) We, article writers, might need somebody to correct the grammar in works. I strongly suggest you get yourself a copy of open office so that you pass over out review copy. LOL Seriously I type way to fast for my mind. I hereby solemnly promise to take time to ruminate, ponder, and think imaginatively before I answer another Struts design email. Damn, that boy is so fresh. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Resource Bundle Prototyping
Can we remove this spam trap user [EMAIL PROTECTED]'? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 August 2003 09:54 To: [EMAIL PROTECTED] Subject: Re: Re: Resource Bundle Prototyping This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] --//-- I chose my words carefully when I said ActionContext interface. I *think* we can all agree that if we added this it should be an interface :-). ---- Why would want the ActionContext to be an interface? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: 11 August 2003 14:47 To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. +1 Aggregate ActionForm,ActionMapping,HttpServletRequest,HttpServletResponse into one object. This is what I have done for Struts 1.0.2 old project in base action class and for this new one at Royal Bank of Scotland. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] --//-- The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. If an action forward requires special business requirements then I can see both advantages and disadvantages. The advantages is that such a new ActionForward could add special attributes to the response that are not concerned with the Action logic. The disadvantages is that it is open to abuse. Bad programming could introduce another layer of dispatching in the ActionForward code. You would get mini-MVC nested inside another MVC, which looks like Hierarchical MVC I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. If you wanted to develop a skinnable web application for example personalisation this new ActionForward might be the way to go. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. Would this new ActionForward be created each time like it is now? Or would it become a dynamic singleton? The problem is not necessarily interacting with the business tier, but making any such interaction to a minimum. The probably means delegation, or caching, or something else to add decoration. Ideally the Struts Action such grab all the business logic for you and then store this information for you. If you are developing a new Action Forward, may be take advantage of this fact, and pass the business info to this new object at construction time. --//-- -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Struts Composable Request Process (was RE: ActionForwards, et al)
-Original Message- From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] --//-- Craig R. McClanahan wrote: On Tue, 12 Aug 2003, Peter A. Pilgrim wrote: So we could have convenience methods such as StrutsWebContext scontext = (StrutsWebContext)context; // Where ``StrutsWebContext'' is a type of ``ServletWebContext'' ActionForm form = scontext.getActionForm(); ActionMapping mapping = scontext.getActionMapping(); If we're talking about a Struts2 world (where we're willing to reconsider the calling sequence of an Action anyway), wouldn't it be better to make StrutsWebContext just extend WebContext instead of ServletWebContext? That way we could have transparent support for servlets and portlets. So instead you would make convenience method from WebContext instead I see the `WebContext.getRequestScope()' returns a mutable map of attribute values. In other words they are derived from `ServletRequest.getAttributeNames()'. But looking at the current Struts 1.1 library would you for compatibility reason also supply the `HttpServletRequest' object to Struts users? HttpServletRequest = StrutsWebContext.getRequest(); // convenience method and like wise `HttpServletResponse' object? Another import idea is that, if we wanted, we could also add other other convenience methods to the context without breaking the signature. My question above. And presumably we [as application developer] will be able to subclass the ServletWebContext and add application features like Single Sign-On / Security / personalisation etcetera. We will be able to configure Struts Module to use our custom `Context' instead of the Struts default context. Yep this is looking sexy. Yep ... lots of interesting room for playing around here. To say nothing of the fact that you can compose your own request processor pipeline to boot. Moving swiftly back to the original design reason. The [old] request processor is now effectively a `Chain' isn't it? ( ... I will now continue this note at work ) -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' In the excitment I got caught up the discussion about customised action forward, whereas the original design intention got chucked to the side, namely a ``composable request processor''. So let me spend some time discussing this: Now I am at work. I said `RequestProcessor' currently could be rewritten as a `Chain', because it aggregates a many `Command's. But I am wondering about that statement. It would be seem to me `RequestProcessor' is a very complex `Command' Going back to the original Decomposable request Processor thread there were at least two concerns: 1) How delegate or nest processors so that they do the right thing. 2) Deciding which methods of the current processor should be decomposed. 3) Configuring the chain of processor from XML. Delegation: I believe would be like Servlet Filters as they are implemented now. If we have servlet filters A and B , then we know that if filter A chained to filter B. The final effect is not necessarily equal to B followed A. Methods: In the current request processor there is one method `process()' which has a default implementation: public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException This method calls other ``process*'' methods. processLocale(request, response); ... processPreprocess(request, response); ActionMapping mapping = processMapping(request, response, path); ... ActionForm form = processActionForm(request, response, mapping); processPopulate(request, response, form, mapping); ... Action action = processActionCreate(request, response, mapping); ... ActionForward forward = processActionPerform(request, response, action, form, mapping); My question is if we make `RequestProcessor' a common-chain `Command' then do then in turn make it call other `Command' in order to emulate all the `process*()' calls. For example // RequestProcessor implemented as complex `Command' // Assuming we get a web context from somewhere, StrutWebContext sc = ... ; processPreprocessCommand.execute( sc ); ... ActionForm form = (Action) processActionCreate.getAttributes().get(ActionForm); ... processActionCreate.execute( sc ); Action action
RE: DynaActionForm.getMap() change
Craig, Just got back from Holidays. Am I already late to party? How about `DynaActionForm' with unmodifiable map `MutableDynaActionForm' with a direct modifiable map. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: 16 July 2003 20:30 To: Struts Developers List Subject: Re: DynaActionForm.getMap() change On Wed, 16 Jul 2003, Rob Leland wrote: Date: Wed, 16 Jul 2003 14:58:45 -0400 From: Rob Leland [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: DynaActionForm.getMap() change David Graham wrote: DynaActionForm.getMap() returns the Map that the properties are stored in without copying it to a new Map instance or wrapping it in an unmodifiable Map. IMO, we should treat that method with much more care and return an unmodifiable view of the Map considering it's mainly to be used in JSTL tags. Does this solve a problem that you or others have encountered in practice ? I can see where a use who retrieves the Map and then modifies it could accidentally (or on purpose) violate the type safety checks that the normal get() and set() calls provide for you. -Rob Is anyone opposed to this idea? My only concern would be the performance impact of this, especially if it happens more than once in the same page (say, because you used the same dynabean in more than one EL expression). An alternative approach would be to do what someone else suggested and make DynaActionForm implement Map directly -- but make it effectively immutable by throwing UnsupportedOperationException for Map method calls like put() and remove(). I don't *think* there are any method signature overlaps that would cause us any grief. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: 04 June 2003 12:05
To: Struts Developers List
Subject: Re: composable RequestProcessor
I still don't see why processing an action request is any different
than processing a validation request.
Formed like the validation, the default request chain looks like this:
process=processLocale,processContent,processNoCache,processPr
eprocess,processMapping,processRoles,processActionForm,process
Populate,processValidate,processForward,processInclude,process
ActionCreate,processActionPerform,processForwardConfig
where each of these have been defined as a Subprocessor (e.g.
Validator).
As it stands, many of the process methods take different
signatures and
return different objects. But that could be changed so that they pass
around a single data transfer object with a place for all the usual
objects (request,response,mapping,form,action,forward).
Right
You can dismantle the signature and create a `ProcessorContext'
class ProcessorContext {
HttpServletRequest request;
ActionMapping mapping;
...
HttpServletRequest getRequest();
ActionMapping getMapping();
...
}
class RoleProcessor extends GenericProcessor {
void processRole( ProcessorContext c) { ... }
}
class IncludeProcessor extends GenericProcessor {
void doInclude( ProcessorContext c ){ ... }
}
This could work well. How does this processor pattern
solve the problem where the RequestProcessor stores
data member? E.g. The list of Actions recorded against
a ModuleConfig.
Whether each component in this sequence is systemically compatible or
whether the order of the processes makes sense, would be the
developer's
responsibility, just as it is for defining a chain of Validators.
Right now, the framework describes a lockstep lifecycle. But
that really
isn't the framework's job. The framework should provide a pre
configured
default lifecycle, but the developer should as much freedom
as possible
to define whatever lifecycle works best for a given application.
The distribution could ship with a library of Subprocessors
(just as we
ship with a library of Validators). To use Tiles, you would make the
appropriate changes to the process property to load the Tiles
Subprocessors. If someone wanted to handle a different
extension point
differently (or insert a new one), they could add a
Subprocessor to the
library (as we can with validators), and amend the process property.
So there would be no pre-ordained processABC and processXYZ
methods or
call sequence. The processor would call each process in turn until
someone cried stop or the sequence was complete. You could
put as many
or as few Subprocessors into the sequence as you liked, same
as we can
do with Validators.
If you look at the Tiles source code, then you can see there
are calling initialisation methods. SHould these be also
`processified'?
A radical extension, like Tiles, may also need to subclass the main
Processor (aka the RequestProcessor) that would call the
individual
Subprocessors, but hopefully the methods that it overrides (like
internalModuleRelativeForward) won't matter to the other
Subprocessors.
Or, maybe if Tiles does not have to live within a lockstep lifecycle,
there might be a better way of interpolating the
processTiles step, so
that it doesn't need override internal methods.
So, anyway, the idea is that there would be a Subprocessor
interface and
concrete implementations for each of the existing process methods (as
individual classes). The existing RequestProcessor(s) could
implement a
Processor interface. The new ProcessManager could also implement the
Processor interface but call individual Subprocessors from within the
process method. (You might be even be able to do a concept
test with a
RequestProcessor subclass that called inner classes based on the
existing processes.) Which Subprocessors the ProcessManager calls in
what order would be configurable.
One question. Is a `ProcessManager' a ``RequestProcessor''?
What you have described is a sort of master delegation pattern.
Where you already have a plug-in architecture as before
in Struts 1.1 a `RequestProcessor'.
Now you want to extend into a manager interface with the
possibility to delegate methods to other objects.
If this is what you are saying this may solve the issues.
I think Matthias touched on the problem that the TilesRequestProcessor
was doing. If it was checking that the RP was subclass or assignable
against itself. If it was not it would throw an exception.
Can a subprocessor check itself for compatiblity as the Tiles RP does?
While not as simple as what we have now, it would be more extensible,
and has the virtue of using the same implementation pattern
as another
Struts component, the Validator. Which also means that ProcessManager
Struts Module [RE: composable RequestProcessor]
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] David Graham wrote: This reminds me of modules where they sounded like a great idea and then there's nobody to support the bugs. Amen to that, brother. http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev @jakarta.apache.orgmsgId=133116 So Modules are effectively dead(wood). Is that what you are saying? The only problem I think I have with modules (am I have never used in anger) is that they do not inherit resources or the actions of the default module. If they did writing Expresso sub-applications would be a cinch. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
If RequestProcessor becomes an interface then you ought invent
a RequestProcessorManager interface, which is an object
responsible for managing and invoking request processor.
In other words we have a manager and worker children.
If not the controller XML needs changing. How about
manager class=ControllerManager
controller class=TilesRequestProcessor /
controller class=FoobarRequestProcessor /
controller class=AcmeRequestProcessor /
/manager
I'm not sure how this is different than the proposal to
change the xml to
support RequestProcessors on a method level. Struts would
invoke the one
registered processor and it would be up to that processor to
act as manager
if needed.
For Expresso I too have subclassed the TilesRequestProcessor
for our own ExpressoRequestProcessor. Can a module have
more than one controller?
In the future you could have ExpressoRequestProcessor implement a
RequestProcessor interface and dispense with the subclassing
altogether.
Your ExpressoRequestProcessor would act as the manager (using
composition)
if you needed to invoke multiple processors.
I agree with the XP philosophy that often simpler is better.
So, how does
the interface not meet your needs?
An interface should be easy to construct aggregated request processors.
If you are saying
import org.apache.struts.mythical.RequestProcessorInterface;
class FooRequestProcessor implements RequestProcessorInterface
{
RequestProcessInterface tiles = new TilesRequestProcessor();
RequestProcessInterface jndi = new JndiRequestProcessor();
public Action doForward( ... ) {
return tiles.doForward( ... );
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processBoth( ... ) { // Invented method!!
jndi.processBoth(...);
tiles.processBoth(...);
}
}
Yes. You can get away with interface. Obviously it is not
the generic ideal solution, but you can aggregate the functionality
of the request processor however you like. Sure coding is a pain.
Yes. It is also backwards compatible with 1.1RC1/CVS
Deja vu multiple inheritance C++/. Surely not?!
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***
Visit our Internet site at http://www.rbsmarkets.com
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
-Original Message- From: Matthias Bauer [mailto:[EMAIL PROTECTED] I will try to wrap up, what we are up against: The current RequestProcessor implementation does not support chains of request processors. So the developer has to decide which request processor to choose. This brings him into a dilemma, if he wants to use two struts extensions that both implement their own request processor, e. g. ExtOneRequestProcessor and ExtTwoRequestProcessor. Only if one of the two extensions provides a ExtOneExtTwoRequestProcessor that integrates the functionality of both of them, the two extensions can be used together. For two extensions being around this can be accomplished. But as soon as the number of extensions grows beyond 2 (which has already happened) this is fairly impossible. Providing a RequestProcessor interface does not really relieve the situation. Even though it will make it easier to compose a request processor from other request processors, a subclass for each possible combination of request processors must be implemented. Thus, by now I believe the request processor architecture should be changed more fundamentally to allow a more selective change of functionality. Maybe they should be working more like servlet filters, so they can be chained? I disagree here. There are far too many methods in the RequestProcessor class to delegate. The question is which method of which controller do you call, and in what order? My XML config approach tried to address this, but I am in design flaw. The cost of making a generic XML approach compared to getting your finger out and coding the aggregated methods way exceeds the effort. The controllers that I have seem only subclass one or two methods of the RequestProcessor class itself. Compared your approach and the StrutsChaining guys and realise there are only intercepting the ubiquitous ``execute'' Command method, and not all ten `process*Whatever()' methods. --/-- -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: 02 June 2003 15:12
To: [EMAIL PROTECTED]
Subject: RE: composable RequestProcessor
An interface should be easy to construct aggregated request
processors.
If you are saying
import org.apache.struts.mythical.RequestProcessorInterface;
class FooRequestProcessor implements RequestProcessorInterface
{
RequestProcessInterface tiles = new TilesRequestProcessor();
RequestProcessInterface jndi = new JndiRequestProcessor();
public Action doForward( ... ) {
return tiles.doForward( ... );
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processBoth( ... ) { // Invented method!!
jndi.processBoth(...);
tiles.processBoth(...);
}
}
That's exactly what I had in mind.
Yes. You can get away with interface. Obviously it is not
the generic ideal solution, but you can aggregate the functionality
of the request processor however you like. Sure coding is a pain.
Can you explain why it's not generic, ideal, and a pain to
code? To me, it
looks straightforward. Remember that this functionality is
to support the
*few* people that will need it. Most Struts apps will use
the standard
RequestProcessor or TilesRequestProcessor. Simple is better
in edge cases
:-).
Why of course. It's the oldest adage in the book.
You dont get nothing for free! You must code.
If we want to configure each method of the processor in
struts-config.xml we
may as well design it as Servlet Filters.
Yes. It is also backwards compatible with 1.1RC1/CVS
Deja vu multiple inheritance C++/. Surely not?!
This is standard OO composition, not a mimic of multiple
inheritance (yuck).
For my purposes then a interface approach would work.
This is the simplest. I want to the same flexible
as I have in the `ExpressoRequestProcessor'. Ok I am
no longer subclassing `TilesRequestProcessor' but I
am now aggregating. I do not care really. What is important
is that the next guy can take my expresso
controller and also aggregate in his
`BigInvestmentBankRequestProcessor' /. Also if I decide
to aggregate in `ExpressoRequestProcessor' new
`FandangleRequestProcessor' my big investment bank
customer also gets that as a bonus.
But there is nothing to prevent the most ardent coder
building the XML configuration composable
controller if he or she wants to.
Compatibility, compability, compability.
Comprehende, cappiche, understand.
----
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
Visit our Internet site at http://www.rbsmarkets.com
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
The controller that I have seen, appear only to subclass one or two methods.
In other wards the controllers are specialising certain methods only.
Some of these methods are returning an object. Be it an ActionForward
or java.lang.String at some point you have to decide which return
value should be returned.
ActionForward doForward( ... ) {
ActionForward f1 = tiles.doForward();
ActionForward f2 = expresso.doForward();
return f1 // or is f2
}
Any generic XML configuration for composable request processor
has to solve this problem satisfactorily.
There is high investment time for the XML configuring approach
compared to straight aggregation approach with the interfaces.
It is quicker and may be easier to write aggregated controllers.
What is the URL (strutschaining.sourceforge.net)?
The Strutschaining guys only have to deal with one method
Struts' Action.execute(...) method. They have build a
separate XML daisy chain, but it is easier for them because
there only one method to intercept. RequestProcessor has
lots of `process*' methods, the solution is not trival.
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
-Original Message-
From: Matthias Bauer [mailto:[EMAIL PROTECTED]
Sent: 02 June 2003 15:55
To: Struts Developers List
Subject: Re: composable RequestProcessor
Rephrasing it, would help me, too ;-)
Brandon Goodin wrote:
The controllers that I have seem only subclass one or two methods
of the RequestProcessor class itself. Compared your approach
and the StrutsChaining guys and realise there are only intercepting
the ubiquitous ``execute'' Command method, and not all ten
`process*Whatever()' methods.
Peter,
I've been following this thread. Very interesting. But, you
lost me at the
afformentioned paragraph. Your english got a little fuzzy
:-D. Could you
please explain your point a little clearer. It sounds like a
beneficial
point. But, I'm not sure if I'm understanding it correctly.
----
Visit our Internet site at http://www.rbsmarkets.com
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: composable RequestProcessor
-Original Message-
From: Matthias Bauer [mailto:[EMAIL PROTECTED]
I am very much in line with you. Where do we go from now? It
would be a
pity if we let the ideas drain, we discussed here.
--- Matthias
Andrew Hill wrote:
snip
This leads to a proliferation of classes. The standard Java
way of dealing
with large interfaces it to provide an Adapter class that people can
subclass and override the few methods they need.
/snip
I can see how your worried that we will end up with a
truckload of classes -
and we certainly will end up with a lot more interfaces
(drool/) (might be
an idea to have a requestprocessor package!) but I still
reckon your missing
the point mate.
The idea is to be able to break out the different bits of RP
functionality
into different classes that you can plug in to customise
that specific
process *if necessary*. Now these dont HAVE to be different
classes, but the
idea is to allow them to be if you have to so that your not
stuck with the
current situation of one big uberProcessor that is a take it
or leave it
proposition (well ok, so you can subclass it of course, but
that doesnt
really make life easy if you also need to subclass another
one for other
bits of the functionality).
If you are going to break out the different methods of the RP
in to separate interfaces, then consider if some of the
method e.g `process*' can be grouped together. Hence
we reduce the number of interfaces.
Just looking at the Javadoc for the request processor
interface reveals some sub processor groupings:
interface ActionRequestProcessorInterface {
Action processActionCreate( javax.servlet.http.HttpServletRequest
request,
javax.servlet.http.HttpServletResponse response,
ActionMapping mapping) ;
ActionForm processActionForm(javax.servlet.http.HttpServletRequest
request, javax.servlet.http.HttpServletResponse response, ActionMapping
mapping) ;
ActionForward processActionPerform(javax.servlet.http.HttpServletRequest
request,
javax.servlet.http.HttpServletResponse response,
Action action,
ActionForm form, ActionMapping mapping) ;
}
interface DispatchRequestProcessorInterface {
void doForward(java.lang.String uri,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response) ;
void doInclude(java.lang.String uri,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
}
Id say most of the time you would - as now - use the standard request
processor that comes with struts *however* you can
specifically override
certain bits of it to do what you need. You can do this now
of course, but
the difference in the multiple interface approach is that
Joe User can take
the processXXX class from struts extension FOO and the
processYYY class from
extension BAR and use them together without having to
analyse the source and
write his own third class to unite the two in some kind of
dodgy shotgun
marraige.
Would grouping the interfaces as I have done above actually
solve this problem? If you have two request processor
that implemented my `DispatchRequestProcessorInterface '
as above you would still have the same messy aggregation
problems as above, albeit is lesser number of methods
to consider. I am unsure if this is easier.
There is another question here, or couple.
By making a request processor an interface you pass on
the concrete details, the actual whereabouts of the
data attributes and the other object instance data
members to some other class X out there.
If you look at the javadoc for the default `RequestProcessor'
it has a list collection of Action objects. This is a map collection
of all the actions that are configured via XML for this module config.
When you start delegating or aggregating request processors, you
must ask the question, in which controller has the module `Actions'.
For example
class AcmeRequestProcessor extends RequestProcessor
implements RequestProcessorInterface
{
RequestProcessorInterface tiles = new TilesRequestProcessor();
public void whereAreMyActions( ) {
// Which is the correct collection actions
// for this module config?
this.actions.get(/Login.do );
// or
tiles.getAction().get(/Login.do );
}
I think we have NOT been considering the data members of the
current default controller (RP).
New accessor and mutators would be required, as I hinted with
the ``Map getActions()'' call above.
May be this is a separation of concerns design. The multiple
interface no longer sounds right, especially with the data
members. I am starting think there could be performance
problems if we start delegating calls ad infinitum too.
May be the
RE: Forcing or replacing a request processor version 1.1 beta3 -
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 13 February 2003 17:48 To: Struts Developers List Subject: RE: Forcing or replacing a request processor version 1.1 beta3 - On Thu, 13 Feb 2003, PILGRIM, Peter, FM wrote: Date: Thu, 13 Feb 2003 17:31:24 - From: PILGRIM, Peter, FM [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Forcing or replacing a request processor version 1.1 beta3 - -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] - I do not want to change the configuration for all time. I alway want to suggest at initialisation that object class B should be used instead A and do that programmatically. Well, you can specify your own config objects on some struts-config.xml elements at deployment. Couldn't you write a config object that handled the required behavior internally? Yeah! You have a point I could subclass the ModuleConfigImpl and set the request processor. Seems pretty drastic for a such a simple task. Am I missing something, or can't you just say: controller processorClass=com.mycompany.MyRequestProcessor/ and be done with it? Craig I certainly could do that and I am doing that, but I want to force the custom request processor, because I am package Struts as part of Expresso? For 2.0 we should look at the config subsystem and maybe define them as interfaces and use a factory to get the implementation class. Then, maybe instead of specifying config subclasses in struts-config.xml we would specify the config factory to use. IMHO, this would make the configuration much more flexible. David ---- -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forcing or replacing a request processor version 1.1 beta3 -
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: 14 February 2003 14:39 To: [EMAIL PROTECTED] Subject: RE: Forcing or replacing a request processor version 1.1 beta3 - I certainly could do that and I am doing that, but I want to force the custom request processor, because I am package Struts as part of Expresso? What do you mean by force? If you mean that you don't want your client to be able to change the request processor, I think that's a bad idea. Why not just advise them that your request processor or a subclass of it needs to be used? Perhaps bad choice of words. I want my custom ExpressoRequestProcessor to be default one at initialisation time, instead of the standard RequestProcessor. Basic I want this `B' to be default one, instead of `A'. In other words I want to save users time from defining it in XML config file. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: It's Valentine's Day, where are we?
It's valentine unfortunately I am now, just leaving work, Struts is not my sweetheart. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 14 February 2003 17:20 To: Struts Developers List Subject: Re: It's Valentine's Day, where are we? On Fri, 14 Feb 2003, James Turner wrote: Date: Fri, 14 Feb 2003 12:16:36 -0500 From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: It's Valentine's Day, where are we? The initial plan of action was to have an RC1 today. We currently have 6 outstanding bugs: 12573 Handling of HTML-Checkboxes and (dynamic) FormBeans result i This one is not a bug -- see the comments I just added when I closed it. I will look at the ones below tonight, but probably won't be able to do much before Saturday on them. ---- It's valentine unfortunately I am now, just leaving work, Struts is not my sweetheart. .. I need the human touch, .. (sung by 80's artist) -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forcing or replacing a request processor version 1.1 beta3 -
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] On Fri, 14 Feb 2003, PILGRIM, Peter, FM wrote: Am I missing something, or can't you just say: controller processorClass=com.mycompany.MyRequestProcessor/ and be done with it? Craig I certainly could do that and I am doing that, but I want to force the custom request processor, because I am package Struts as part of Expresso? How about defining an ExpressoPlugIn that configures everything you need at startup time? PlugIns run after the struts-config.xml file has been digested, but before the configuration information is frozen, so they can do things like: ModuleConfig modConfig = servlet.getServletContext().getAttribute(Globals.APPLICATION_KEY); ControllerConfig contConfig = modConfig.getControllerConfig(); contConfig.setProcessorClass(com.mycompany.MyRequestProcessor); This technique can be used for pretty much any sort of modifications to the configured information. Another alternative (recently added in the 1.1 tree) is to add some Digester rules that are included in the set used to parse struts-config.xml (see the rulesets init parameter on ActionServlet). If you couple that with turning validation off, you can even add additional configuration elements and attributes into the standard config file -- I think the STXX folks are planning to take advantage of this to define their processing pipelines inside an action element. Thanks a lot Craig, After the valentine, I got some work to do now on Sunday morning! -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers
-Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] ---- Sigh. I can see this now. For reference, section 10.1 (Simple Tag Handlers) of the JSP specification, in the section Properties, has this statement: Once properly set, all properties are expected to be persistent, so that if the JSP container ascertains that a property has already been set on a given tag handler instance, it needs not set it again. User code can access property information and access and modify tag handler internal state starting with the first action method (doStartTag) up until the last action method (doEndTag or doFinally for tag handlers implementing TryCatchFinally). If we want to release Struts-EL with 1.1, I guess we'll have to advise users to turn off tag pooling in their containers. Will that work? If I now clearly understand how this works (we'll see), I think I know how to fix this, but it will take considerable manual labor. In short, I'll have to change the source code for every EL tag class, and every EL tag BeanInfo class, adding shadow attributes and getters/setters for every tag attribute. Although this will be a lot of typing, it's very straightforward. ---- No. I dont think so. You just have to make sure that the attributes are treated as read-only values, if you need to modify an attribute use the auto scope. A case in point is accessor/mutator methods for nested collaborating tags. You can happily ignore the above advice for any tag property that shared between tag classes, as long as you do expose the property as tag attribute in the TLD. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Proposal] Migrate to Dependency on commons-resources
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] ---- Will making this change beg another beta release cycle? Or, do we we already anticipate a Struts 1.1 beta 4? If we are going to need a beta 4 anyway, then, sure, lets do it now. If there is any chance that beta 3 might otherwise go to a release candidate, then let's make this part of a *very early* 1.2. At some point, we need to develop the habit of releasing after every new feature or three =:0) Well that begs the question if there are any known show stoppers? What is the aim Struts 1.1 final? I think most of it is there in place. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-5642 Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Proposal] Migrate to Dependency on commons-resources
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] As we've discussed a couple of times, the last major functionality change we had discussed for Struts 1.1 was to migrate to dependence on commons-resources, rather than the proprietary message resource facilities inside og.apache.struts.util. As you might recall, Michael Schacter took a first crack at factoring out the Struts resources classes out to create this commons package, which is currently in the sandbox. I've recently gone through it, and did a major refactoring of commons-resources, to the point where I'm now ready to propose that we modify Struts to depend on it. I'd like the other committers to evaluate the current state of commons-resources, and my proposed integration plan below, to see what they think of this idea. The nightly build of commons-resources.jar included in recent Struts nightly builds is the code that I'm proposing. You can see the Javadocs for this code at: http://jakarta.apache.org/commons/resources/api/ and get the sources via either CVS (from jakarta-commons-sandbox) or nightly snapshots: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ In terms of Struts integration, I propose: (1) Most Struts classes declare a static MessageResources instance for the messages unique to that Struts package. For example, org.apache.struts.taglib.bean.CookieTag has this: protected static MessageResources messages = MessageResources.getMessageResources (org.apache.struts.taglib.bean.LocalStrings); This would be migrated to the new Messages class from commons-resources: protected static Messages messages = Messages.getMessages(org.apache.struts.taglib.bean); The calls to actually retrieve message strings are compatible with the existing code, as well as the properties files used to acquire the message strings, so no other changes should be required. (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers around equivalent functionality from commons-resources (much like GenericDataSource now wraps commons-dbcp), and deprecate them. This protects existing apps that are customizing these APIs, but allows us to remove the o.a.s.u classes in a future version. (3) Modify the message-resources initialization element to allow the selection and configuration of an appropriate ResourcesFactory from commons-resources, wrapped by a Messages instance. This is primarily a change in the interpretation of the factory attribute, and should not affect anyone that uses the current default. (4) Modify all internal uses (including in tag libraries) of org.apache.struts.util.MessageResources to use org.apache.commons.resources.Messages instead. This will be transparent to users that use the standard implementations, but will require folks who have subclassed the MessageResources classes to migrate their code as well. What do you think? Should we go ahead and do this migration? Is the commons-resources package as it stands now as complete and functional as it needs to be (obviously, it'll need to be promoted to a standard Commons package and released so we can rely on it, which will require a couple of volunteers willing to help me maintain it). Should we do the entire migration outlined above, or maybe only part of it? Thoughts, please. Craig -- The ResourceFactory implementation. Would it affect how the messages are retrieved? For example if you have a merged resources that does the following DBResources (1) Boot strap read properties from a flat file (2) Reads some JDBC properties from (1) if any uses them open a connection to data database. (2a) Read properties from database, these overwrite any flat file properties. (3) Repeat for any extra databases. Presumably one would need to write a new `ResourceFactory' implementation and that would be it. Thought? -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-5642 *** Visit our Internet site at http://www.rbsmarkets.com This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For
