On Mon, March 7, 2005 2:23 pm, Rick Reumann said:
> I started reading a bunch of these threads in reply to the above and I
> do think that I'm seeing a trend of over-complification here (yea, made
> up word:). I do like the concept that JSF takes, but from some of the
> posts I've read, some are complaining about JSF being too page-centric.
> Personally I like the page-centric approach and find that it fits the
> mold of how typical web apps work. I'd say 99% of the time people use
> Struts in a page-centric manner.

Keep making up those words Rick! :)

I think the debate, in my mind at least, is what the term "page-centric"
really means.  The definiton I've been going with is that if all the
functionality for a given page is specific to that page, then it is indeed
a page-centric design.

The problem I personally have with that is that if you have a dropdown on
three different screens that just happens to have the same data in it (not
something unusual really... think maybe a list of U.S. states), then you
have no elegant way to deal with that IMHO.

A good developer is going to have some sort of class to get the data for
the dropdown, but then you have to call on it from three places.  I'd
prefer something like that be declarative.  You make a comment later on
that I absolutely agree with about having the code in front of you instead
of having to dig through config files and figure out what some framework
is doing for me behind the scenes.  Generally I agree with that.  But, I
think there are places its better to go the declarative route, and I sense
this might be one of them.

> Sure you can create a ton of cool ways to handle the setup of Lists into
> scope, but I still find it very simple to have in my Dispatch Action a
> simple prep() method that handles this.
<SNIP>

Your approach is indeed nice and simple, and echoes what I tend to do. 
But, I'd prefer to not even have to write that code into every Action
where such setup-type functions apply.  I'd prefer it be configurable,
like so much else of Struts is.

> The only time the above is annoying is if you happen to use your update
> dispatch method from several different places and your resulting forward
>   can go to many different pages (not all of which would need the "list"
> placed in request scope.)  (Even if you end up going to different pages
> from reusing the above Dispatch update method, the worst case scenario
> is that you'd typically have a few extra things stuffed into the
> request. Yes, if logic is way different you could need to use different
> lists with the same name, etc.. but again how common is this? I still
> tend to think it's best to solve and code for the 90% rule.)

The thing is, I'm not convinced the scneario you point out as being not
too common actually IS that uncommon :)  I haven't done a ton with
DispatchActions, but I *have* on many ocassions had an Action that was
callable from a number of different pages, and the forwards were indeed
different.  My experience would tell me that such a scenario happens more
than the 10% of the time you think it does :)

In such cases, being able to declaratively specify which setup functions
to perform based on the particular mapping would save me a lot of
redundant coding.  I handle it now by forwarding to Actions that do the
setup I need, but that makes for a more verbose struts-config.xml.  Just
as annoying but in a different way!

> And although many have proposed nice ideas one of the problems is as
> Leon mentioned:
>
> "I find it hard enough to manage all the config files I have to manage
> right now (struts-config, resources, tiles-definitions, factories, and
> so on), I would be the last one to introduce one more."
>
> And the above point is the exact problem with some of the solutions. And
> yes Tak I have looked at OzStruts briefly and to me it overcomplicates
> things because it's just one more thing a developer needs to learn, when
> the standard practices solve 90% of the problems.

No argument here!  Hence the reason I didn't want to add a new config file
at all... my solution centers on the idea of adding one new element to an
Action mapping, <actionSetup> (although, as I wrote that just now, I think
<mappingSetup> maybe makes more sense... perhaps even making these
attributes of a <forward> makes more sense... eh, thinking out loud now!).
 I doubt very many people would find this onerous.

> To the initial poster (Ben), I'd opt for the simple prep() method unless
> it doesn't meet your needs. Another benefit is if someone has to look at
> the code, it's easy to find what is going on. Nothing to me is more
> frustrating than working on someone's application and trying to figure
> out what configuration file is injecting what where and how, or what pre
> and post operations are taking place that are setup somewhere else.
> Sometimes these solutions are needed, I just don't think for the vast
> majority of cases they are.

That's the point I liked! :)  And I don't at all argue with your
suggestion to Ben.  What you propose works, is simple, and I'd bet would
meet his needs.

But, we've kind of hijacked poor Ben's thread and dovetailed into
proposing a more general solution to this very common problem :)

I was hoping to get a chance to implement this today and post it for
everyone to see, but I got hammered at work.  If I can get some time
tonight I may be able to throw it together.  I think then we'd see the
benefits or problems with the idea much clearer.

> --
> Rick

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to