On 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > Very few had the idea of passing ActionForm as VO to persistence > layer. This is some kind of backwards MVC. Contrary, the idea was to > use BOs in ActionForm with session scope, thus making it a stateful > interactive business object.
Haven't been around the Struts mailing list for five years, have you? :-) > > I am not sold on the idea that presentation should have state. Why? > Presentation presents. Business objects have data and state. If I > aggregate BO into view, I do not break classic MVC design. Instead, I > gain in terms that I have my data in one place instead of two places. > This is classic database rule: if you can have data in one place, have > it there. This saves from discrepancies and is easier to maintain, to > understand and to follow the relationships. > I'll give you one trivial example where view state matters ... lots of applications have a way to select the language in which the user wishes to interact, which should also affect things like date and currency formats. It is ridiculous for the application developer to have to manually set such a property on every request ... that's what frameworks do (and, to their credit, frameworks like Struts and JSF deal with this quite nicely). But it is a *view* tier piece of state, and has nothing to do with the model tier. There are other examples (which columns in a table are you sorting on? Have you applied any filters? Is this tree node expanded or collapsed?) but the point is clear ... there is indeed such a thing as view tier state that is totally independent of model tier state. > Treeviews may contain business data, or may not, so I see value of > having things like treeviews in view layer. Comboboxes are usually not > a business data, busines data is only one value from this combobox. > Regular data that comes from database and edited by user, is busines > data, and it is much easier to pull it from a real BO and to display > it. > So, are you saying that a tree view should *not* remember which nodes are opened and closed? > > The JSF recommended pattern actually lets you do "dispatch action" > > sorts of things, but a bit more easily :-). > > JSF isolates business data from widgetse even further. Also, JSF is > not advertised as framework where a resource returns different views. > Instead, it is advertised as Page Controller, which works well for > former desktop programmers, but does not fit HTTP ideology. Not that > it is not possible to emulate Front Controller in JSF, but it takes > some tricks for that. > > Same goes for ASP.NET - easy to develop, clumsy to use. Of course, > Microsoft provided option to not use _viewstate, but everybody uses > it, because it is used in sample code and is considered standard. I am > glad that JSF stores viewstate on server by default, this is much > better. Why should *JSF* be required to play the front controller role you describe, when the servlet API provides clearly adequate features if that is what you want to do? That suggestion reminds me of one of my first exposures to "frameworks" a couple decades ago ... Microsoft's MFC framework for writing Windows apps. If you could craft your requirements in terms of the APIs that MFC provided, you were going to be OK ... but woe be you if you wanted to go outside the framework! Modern frameworks should be fine grained and composable ... combine the pieces you need in order to accomplish your application requirements. You, as an application developer, should *not* be forced into "my way or the highway" decisions simply because the developers of your framework did not anticipate your particular use case. After all, why would anyone care about formalized "dispatch actions" in a Struts environment? You know the answer ... the basic framework doesn't know how to deal with the complexities of this use case. You've found a nice answer, but it's constrained by trying to be compatible with Struts 1.x. That's a *perfectly* reasonable goal, if that is what you are after -- that's just not where I am now. Where I am, it's a much simpler problem if you remove that constraint. The exact same design principles can be expressed much more elegantly if you don't need to worry about implementing Action or ActionForm. > > Michael. > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
