If you view the setup functionality as a discrete service, then it is reasonable to say that particular service might be called from multiple places.
For instance, you use a master-detail example... If it is really true that the list of master items, as well as the list of detail items, is something that will only exist on that page, then great, I wouldn't argue at all :) However, to me that looses some flexibility...
If we say "ok, we have a service that displays a list of master items", and "we have amother service that displays a list of detail items", then the question of whether this is the only page that needs those services or not becomes moot. More importantly though, when another page is inevitably introduced later that needs them, I'm all set to provide that.
I'm using the term service here, but I don't mean it in the sense of SOA or Web Services specifically. I simply mean the way you view a particular component... Rather than saying "component X services page X", why not say "component X provides service X, and if page X uses it, great, and if page Y later needs it, no problem". That's the mentality I'm approaching this from.
I'm not sure anything you have said would preclude you from doing any of this within Shale for instance, but I *do* think it's not the same perspective on it (as Jack said, Shale is page-centric, but I'm looking at things from a decidedly not page-centric perspective). If you see the example configuration I posted a few minutes ago, I think that gives a much clearer idea of how I'm approaching this.
Your comment about binding the list component to some session data is interesting, but I think leads you down a path of a component-based UI design, as JSF is (from my admittedly not full understanding of it). I think this is potentially a powerful paradigm shift, but that's exactly what it is: a paradigm shift. I'm not sure everyone is ready to go there yet. I can speak for myself certainly, and I am not. I remember the days of data-bound controls in my VB work (in my former MS life :) ), and we got away from that in end end, and I think it was the right thing to do. Now we're talking about going back to that, and I'm not sure I'm onboard with it yet...
Jack made the comment (I'm paraphrasing) that this is all good for the tool vendors and for developers that don't have a full understanding of what's going on. I think I would have stated it a bit more dimplomatically, but I don't think he was far off the mark :) The day any half-assed developer can put together a web application using RAD tools is a day I do NOT look forward to, for the same reason I hated all the half-assed developers I knew that chruned out VB craplets like there was no tomorrow... God forbid something goes wrong under the covers and they have to actually look at code.
Come to think of it, I have a great comic strip on my office wall at work... It's a "web developer" fainted on the floor with a group around him. One guy says "give him some air, he'll be OK... he just accidentally saw some HTML generated by his WYSIWYG editor".
That sums it up for me :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
...And I did in fact mean you when I wrote "someone" :)
I generally like the overall idea behind ViewController beans as you describe. If there was one "problem" that I see it is that the prerender() method is specific to the page the bean is associated with. This can be viewed as "good" or "bad"...
The "good" view is a nice encapsulation of the page-related functionality. Also, as you point out, it may serve to eliminate some unnecassery work in some cases, which is nice.
The "bad" view is that if you have essentially the same dropdown on three different pages, as I understand it, you either (a) have to duplicate that setup code in three different beans, (b) call some common class from all three prerender() methods, or (c) call prerender() of one of the beans from prerender() of the other two (assuming that's even allowed).
If the domain data is truly shared across multiple pages, you
shouldn't be setting it up in the prerender() method -- or in a setup
action in Struts 1.x -- at all. Option (d) is best in that case: bind your dropdown list component directly to a list of options that
lives in session scope (if it is unique per user) or in application
scope (if it is common to all users).
The example app for Shale illustrates precisely this approach for populating dropdowns, if you want to see how it looks in code.
Of those options, (b) is the only one that doesn't make me immediately unhappy. But, even that one feels a bit more heavyweight and hacky than it could.
That one is still too much work.
But, don't take that as a criticism of Shale in any way. I'm just thinking along the lines of how I might like to implement it in 1.x, trying to see what ideas from Shale I might like to steal and which I might like to go a different way on :)
Option (d) works great in Struts 1.x too :-).
Your comment about the Tiles Controller is very interesting... If I was to do this, I would think the proper way would be that it should work regardless of whether Tiles is used or not, and in the same way in either case. Clearly if I have to use a controller when using Tiles but something else when I'm not, that's not an optimal answer, to me anyway. I could also make the same argument about the controller as I made about the Shale prerender() method too, but its two different issues I think :)
Use a Tiles controller (Struts 1.x) or Shale prerender() method
(Shale) *only* for the stuff that is unique to this particular page. For example, consider a classic master-detail scenario like "show me
all the orders for the selected customer." Where do you put the logic
that actually performs the appropriate database select (or whatever,
based on the persistence technology you're using)? That's right ...
this is where it goes, because it is unique setup for *this* page or
Tile.
By the way, Shale's ViewController support recently got extended to subviews (i.e. things which are included by <jsp:include> or the equivalent, which is what Tiles does under the covers). Therefore, you'll be able to use exactly the same techniques on either a single "tile" or the entire page, without having to learn two different APIs.
Anything you can do once and cache should be done once and cached :-). No need to execute *any* logic if you can bind to them directly.
Struts: <!-- Assume form bean has a "state" property on it --> <html:select ... property="state"> <!-- Assume appScopeBean is a Java class in application scope --> <!-- with a getStateNames() method that returns an array of State --> <!-- names, and a getStateAbbrs() method that returns an array of --> <!-- State abbreviations --> <html:options ... name="appScopeBean" property="stateNames" labelName="appScopeBean" labelProperty="stateAbbrs"/> </html:select>
Shale: <!-- Assume current customer bean has a "state" property on it --> <h:selectOneMenu ... value="#{customer.state}" ...> <!-- Assume appScopeBean is a Java class in application scope --> <!-- with a getStatesList() property that returns an array of SelectItem --> <!-- instances, whose "label" and "value" properties are the state --> <!-- name and abbreviation, respectively --> <f:selectItems value="#{appScopeBean.statesList}"/> </h:selectOneMenu>
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
