Re: Decomposing RequestProcessor -- Some Code To Play With
Hey guys, this is exactly what pageflow does, though it does more as well. Oh well Im working on a white paper which describes the functionality. How would I go about getting something into the contrib folder? - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 11, 2003 12:23 AM Subject: Decomposing RequestProcessor -- Some Code To Play With During the Decomposing RequestProcessor thread a while back, I hinted that I'd been working on some code to propose for this purpose, but had never had time to polish it enough to check in. Well, I actually took a bunch of time this weekend for precisely that purpose, and have checked in two chunks of code for your viewing and toying pleasure: * A new jakarta-commons/sandbox package called chain that implements the GoF Chain of Responsibility pattern, in a way that lets you compose arbitrarily complex processing chains out of very simple classes, in a variety of different contexts. If you're familiar with Cocoon, think of the site map pattern but without the requirement that every dynamic step be an XSLT transformation. If you're familiar with Axis, think of the way you can compose Handler chains, but without the restriction that it is only useful in implementing a web service. Nightly builds of this package should start showing up tonight at: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/ * A new contrib package in the Struts workspace called struts-chain that is the beginnings of a decomposition of the RequestProcessor processing pipeline, but allows the overall chain to be customzied in much more powerful manners than the way that subclassing RequestProcessor supports. You'll need to grab the CVS source to play with this one. None of the code actually works yet -- it is very definitely a work in progress -- but I *think* we'll be able to end up with something that can be added on to a Struts 1.1 distro. I won't personally have huge amounts of time to work on this over the next few months, but I will definitely participate in discussions and improvements to this code. If it all works out, I'm going to propose something like this as a foundational architecture for a Struts 2.x series that will leverage this design pattern to support extreme customization. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modules vs. Sub-Applications
It would seem like there should be a relatively large gap between 1.X and 2, dont you think? For Struts to maintain it's leadership role in the web app framework, it seems that it must grow significantly. To do that, at some point we'd have to switch over to a different architecture. Much like the commons-workflow package, but customized for web apps. PTS - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 28, 2002 1:11 PM Subject: Re: Modules vs. Sub-Applications On Mon, 28 Oct 2002, David Graham wrote: Date: Mon, 28 Oct 2002 11:24:36 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Would it make sense to keep the current names but deprecate and replace them in a future version (maybe 2.0)? To me, deprecating them in 1.1 would imply that we'd really like to remove them in 1.2 or 1.3 (if there ever was such a thing). And I don't think that's necessarily what we want to do (although it might). If we implemented all of the wild ideas I know of already for 2.0 (such as making the controller a Filter instead of a Servlet), there would likely be very little similarity between 1.x and 2.x other than the product name. We're going to have to very carefully hash out what we think the roadmap should be, before we really have much of an idea on what 2.0 will hold and therefore what deprecstions it might imply. David Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Is FormBean mandatory???
This logic is essentially correct in that the framework needs to process front end stuff prior to mapping to a view object. However, there are good reasons to not want to have a form bean and a view object and an entity bean. Memory usage -- while frivolous object creation is ok in small to medium sized apps, larger apps can have thousands of view, form combinations and object trees. you really dont want to be instantiating a view from the bean and then a form from the view (even though that may be the purest way to do it currently) Ease of development -- dynaForms make for easy form beans but they dont make for easy mapping from form-validate-view-entity. Also, having to glue all of that together creates as much confusion as the original type 1 infrastructures. Maintainability -- the current mechanism is somewhat clugey at best and results in significant conversion code that has nothing to do with business logic. Design Clarity -- I have spent numerous hours with junior programmers in code reviews dealing with inconsistent transformation strategies, in appropriate amounts of object creation, etc. on relatively simple apps. Interestingly enough it does create something of an opportunity. Using proxies and some basic mapping/templating patterns the form bean could be 'split' to represent a combination of the VIEW and MODEL while maintaining there relationship and consistency using mapping/validation language in the config file. Wouldnt that just be cool. Automate the view-form bean up to a certain point of complexity, and then provide programming hooks for more robust functionality. Basically there is an opportunity to take struts one step further by providing apis for app server integration. Paul - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 2:52 PM Subject: Re: Is FormBean mandatory??? On Tue, 9 Apr 2002, Bob Lee wrote: Date: Tue, 9 Apr 2002 13:53:57 -0500 From: Bob Lee [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Is FormBean mandatory??? I think I may need to elaborate before I get flamed. I do *not* suggest coupling your presentation layer and middle tier with a single value object, as it is often the case that your middle tier objects loosely correspond to the data submitted in your form if at all; if they are a lot alike, your application probably isn't doing much. The form bean and value object bean will be similar in the set of properties they expose, simply because the UI in many applications directly mirrors properties in the underlying persistence layer objects. However, they serve different purposes. - The form bean is simply the place on the server side to accumulate the input fields from the screen in an organized way so that you can validate them. You really don't want to start modifying the underlying database information until *after* validation has been successfully completed. Data types (particularly for input fields that are rendered as text boxes) should be strings so that you can redisplay what the user typed if they made a mistake. The only logic in a form bean will typically be the validate() and reset() methods. - The value object is used to either transport the validated properties to the underlying EJB or database layer, and/or to abstract away the details of exactly how persistence is accomplished (so, for example, you could switch from JDBC calls to EJB if needed later). The data types in a value object will typically be the same as the underlying data types stored in the database (int, Timestamp, or whatever). I am simply asking why using a separate FormBean is the best solution. It seems like an awful lot of work, especially if you are just getting/setting Strings. There is a time delay and a feedback loop involved here. Let's see if I can draw it with ASCII art: - Input Form on browser / (redisplayed with previous |data if errors happen) | | | | Submit | v |Form Bean is reset() and |then populated (to deal |correctly with checkboxes) | | | | Validate (if not cancelled) | Error / \ \ Passes | Action Called (goes elsewhere if transaction was cancelled) | | Transfer to | value object | v V.O. sent to the Persistence Layer If you skip the form bean, you have lots of undersireable consequences like updating the value object even when the input data is invalid, not being able to deal correctly with checkboxes, and inability to deal with a Cancel button. If writing form bean classes
Re: Workflow/Pageflow proposal
Actually, I have looked at the workflow piece in commons and do like the way
it is going. Having worked a good deal with Weblogic BPM (Business Process
Integrator) and Tibco Active Enterprise, I do have some to contribute to
that package. However, I have a more struts specific idea in mind. One that
is targeted directly at web applications. I am working on an idea that I
call pageflow which would allow the connectivity of multiple pages in a
single flow. It is essentially an upgraded controller architecture,
targeted at making the development of mini-flows in web apps easier. It is
similar in nature to the wizard concept put forward in the current workflow
proposal for struts. However, my idea is to seperate out the worker part
of workflow, which is intended to get some actual business processing done
(this part would live in the commons workflow package), and the page
controller aspect of struts.
For example, in a recent project using struts, we had 6 different pages
which needed to be accessed under different context. If the user came from
page A and they had selected to transfer Record A then the save button on
page B was supposed to do one thing. If the user came from page C then the
save button was supposed to do another. We also had passive actions that
needed to be executed Event Style so that when the user finally got to page
D something would happen based on where they started. This was not easy to
accomplish given the current framework. First, there was no contextual
navigation or Actions. Second, no events, so page A, in the example could
not setup a listener for arrival at page D, etc. Thirdly we had huge amounts
of data that we had to store in the session per user, which wouldn't be
garbage collected until after the session closed, even if the user were
never going to access it again. One other problem we had was knowing at any
given time what the users context was. We had to develop a way to query the
web engine for variables in the session, request, and applicaiton levels.
Having had the same types of problems in multiple web apps, I came up with
the idea of pageflow.
Essentially, the idea is to create a page concept, similar to the current
forwards declaration in the config file. However these pages would function
differently based on context. These pages could then be connected in
multiple sub pageflows which would have their own a) navigation context,
b) events (there would be application level events as well), c) scoped
variable declaration and storage (again there would still be request,
session and application scopes) and d) ability to call back into a workflow
engine for complex tasks and e) live action links which would allow the
developer to declaratively switch the Action handler and Form clasess. This
would let us do all sorts of interesting things, but the clear benefits in
my mind are:
a) painless garbage collection of pageflow scope variables (read lower
overhead)
b) clear contextual information about a users location and direction
c) allow interesting additions like declaritively going to 2 web pages
(using window.open() javascript) based on a the current variable context
(we've actually had to do this many times in our apps)
d) much lower cost of development of sophisticated web apps (declarative
handling of this type of behavior would have saved at least a couple hundred
developer hours and ours was a simple application)
e) actions could be more fine-grained and more declarative as well. For
example a lot of Action I have seen have things like:
class SaveCityAction{
perform(...){
String subaction = request.getParameter(subaction);
if(subaction.equals(cityOnTheMainland)){ ... }
else if (subaction.equals(hawaii) { ... }
...
After a while this kind of code gets very hard to handle and you then have
to start switching out finer grained actions using javascript (set the html
action to suchAndSuch.do)
f) ability to override behaviour at multiple levels (such as scoped error
handling)
g) ability to create a visual editor
The best way to think about the solution is as a flow chart where pages can
be connected to other pages using either plain Action classes or Activity
connectors (activities would be workflow calls to the commons package on the
backend). Each action would have associated input and output variables which
correspond to the variables coming off of a page (a dynamic Form if you
will) going into the Action and the variables going into the next page.
Anyway, that was kind of fast and furious, and probably sounds a little
jumbled. I can lay it out more elegantly for you, given more time. However,
having built entirely too many of these mosters (web apps), and having
implemented a basic version of this framework (outside of struts) for a
previous employer, I am convinced that developers would love this addition
to the framework.
Feel free to flame away...
Paul Smith
[EMAIL PROTECTED]
[EMAIL PROTECTED
Workflow/Pageflow proposal
Ted, I have a design put together for a pretty significant upgrade to the struts framework which would meet the needs of the workflow requirements. I have set up the struts framework and have started a build structure in the contrib folder on my local machine. However, this is a major change, and I was wondering if I should run it past the group first. I thought it up a year or two ago and just recently decided to graft it onto the struts framework instead of starting my own. I have read the workflow proposal on the web and believe that my design would meet and exceed it in a number of ways. So what do you think? Should I attempt to layout the design on paper for the group (probably take me a while), or build it and then show everybody? Thanks, Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
