Heck, Tapestry is way ahead of JSF, etc. I have no idea why JSF is
seen as new when Tapestry is ahead of the game.
On Mar 11, 2005 8:34 PM, Tak Yoshida <[EMAIL PROTECTED]> wrote:
> Rick,
>
> I really appreciated that you have looked at my small idea.
> Please write or see the sample code.
> You
Rick,
I really appreciated that you have looked at my small idea.
Please write or see the sample code.
You must get something from it, if you like page oriented.
OzStruts is totally different from other page oriented framework,
because it runs on current Struts, meaning it's simple.
I'm personally
An extension of the approach here is what we so with the Oracle ADF
framework, namely that of associating a metadata XML file with the
Action which drives the runtime framework to prepare the bindings for
the page. So this is taking the whole declarative thing that much
further by basically pu
Can you add this XML functionality to the struts-config please? Then I
won't hate you:)
write application for me while I surf web
Frank W. Zammetti wrote the following on 3/9/2005 4:15 PM:
On Wed, March 9, 2005 4:07 pm, Rick Reumann said:
(Hope
What I based it on was a project where we had 3 apps being developed and
I got injected at the user acceptance testing phase. 2 used Spring and
one did not. The client chose to not use EJB Facades, but regular POJO
Facades. In the 2 that used spring it took me approximately 20 minutes
to change b
On Wed, March 9, 2005 4:07 pm, Rick Reumann said:
> (Hope you take the right way Frank.. because it is very cool:)
Of course I do Rick... YOU HATE ME!! :)
Seriously though... I do agree with much of what you say... I've always
been of the "get those stupid XML files away from me and just write so
Fogleson, Allen wrote the following on 3/9/2005 3:21 PM:
I have been there enough times, and I am sure others have, to know that
changing that all in a single file is a LOT faster than going through
hundreds of files searching for "SetupClass1.setupMethod1(request)". Or
the worse case searching for
Fair enough... agree to disagree :) In any case, I would never force
something like this on anyone, it would only ever be optional if I had
anything to say about it, so it probably wouldn't be a problem anyway. As
coded, there is absolutely nothing that says you have to use setupItems,
so that go
We probably have beat this to death, Frank, but having the framework
setup pages with declarations in the action mappings is not consistent
with MVC to my way of thinking. I definitley would not do this. I
like to keep things simpler. But, others seem to like it. So, maybe
you have something th
I can't state it any clearer than I have, or any clearer than another
poster (I forget who) just did a few minutes ago. If for absolutely no
other reason, convenience and ease of change are good justifications.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http:/
Frank, watch that "anal" talk, would you? I could do without that. :)
My point was just that I don't see a problem and don't understand how
this would help.
--
No one ever went blind looking at the bright side of life.
-
To un
c: Struts Users Mailing List; Ben Taylor
Subject: Re: Eliminate Setup Actions
This is more, not less, code, is it not? You have:
setupMethod="setupMethod1" />
which has to be used for all actions that use this, right?
compared to:
SetupClass1.setupMethod1(request)
I don
On Wed, March 9, 2005 3:11 pm, Frank W. Zammetti said:
> On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said:
>> This is more, not less, code, is it not? You have:
>>
>>>> setupMethod="setupMethod1" />
>>
>> which has to be used for all actions that use this, right?
Forgot to reply to that las
On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said:
> This is more, not less, code, is it not? You have:
>
>> setupMethod="setupMethod1" />
>
> which has to be used for all actions that use this, right?
>
> compared to:
>
> SetupClass1.setupMethod1(request)
If you consider lines in an XML
This is more, not less, code, is it not? You have:
setupMethod="setupMethod1" />
which has to be used for all actions that use this, right?
compared to:
SetupClass1.setupMethod1(request)
I don't see the "less code" point. Looks like more code to me, but
just a different kind of cod
More (application-level) code isn't needed... it's just a question of
making it declarative rather than programmatic, which is how so much of
Struts already is.
Here's an example from the example app posted to the Bugzilla ticket I
referenced (ticket # 33935 if you want to download it and try it).
On Wed, 9 Mar 2005 14:07:04 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> But do you see the point in setup functions *outside* an Action's code
> that occurs on the forward-level? Meaning, once an Action returns a
> forward, do some setup based on what forward was returned?
Yes.
rs Mailing List; Ben Taylor
Subject: Re: Eliminate Setup Actions
Many people would suggest that using Actions in Struts would be
preferrable whether or not you need to do any "setup" or any
"processing" in the movement from one page to another in a website.
I think of Actions
But do you see the point in setup functions *outside* an Action's code
that occurs on the forward-level? Meaning, once an Action returns a
forward, do some setup based on what forward was returned?
If so, check out the Bugzilla ticket I opened today where I provide this
functionality, as well as
Many people would suggest that using Actions in Struts would be
preferrable whether or not you need to do any "setup" or any
"processing" in the movement from one page to another in a website.
I think of Actions as places to organize what needs to be done
(processing the request) and providing any
> -Original Message-
> From: Ben Taylor [mailto:[EMAIL PROTECTED]
> Sent: 05 March 2005 08:03
> To: Struts Users Mailing List
> Subject: Eliminate Setup Actions
>
>
> Hi,
>
> Can anyone tell me if there is an easy way to put information
> (required to po
And I've been silently wishing you'd add it, too. :)
We've had discussions about this maybe twice before, and another time
I lit the flame, you responded, but I wasn't able to follow through
with the discussion.
Well, then, now you've gone and done it, Hubert... I've just
committed the basic supp
LOL, sorry Frank, I didn't mean to drown you in documentation. :)
On Tue, 8 Mar 2005 09:31:04 -0600, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti
> <[EMAIL PROTECTED]> wrote:
>
> it might be
> helpful to review those messages as there were
On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
>
> You mean as far as 1.x goes? I'm just looking now to see how the config
> file is read in (haven't played with Digester at all yet). But yes, just
> dropping the doctype was how I was going to, temporarily,
On Tue, March 8, 2005 9:48 am, Joe Germuska said:
> I do think we're pretty close, although not much has happened since
> the last wave of "what will 1.3.0 be" discussions. I know I haven't
> had much time for development and documentation in the last few weeks.
I know the feeling :) I'm actuall
At 9:37 AM -0500 3/8/05, Frank W. Zammetti wrote:
No Joe, you didn't miss anything :) I was already thinking about how easy
this would be under 1.3 too. But, I'm hesitant to start playing with 1.3
until it's actually released (at least in beta). This is an easy add to
1.3, as you indicate, and I
No Joe, you didn't miss anything :) I was already thinking about how easy
this would be under 1.3 too. But, I'm hesitant to start playing with 1.3
until it's actually released (at least in beta). This is an easy add to
1.3, as you indicate, and I'm also looking forward to porting my StrutsWS
pro
hat way?
>>
>> -Original Message-
>>From: "Dakota Jack"<[EMAIL PROTECTED]>
>>Sent: 3/8/05 12:34:50 AM
>>To: "Struts Users Mailing List",
>> "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>
>>Cc: "C
Sorry, I haven't been following this whole thread, but when I saw
this config example from Frank:
>
> method="setupMethod1" />
>
> method="defSetup1" />
>
>
I wondered "why not use chain?"
In Struts 1.3, you can specify a command in the element
which
ECTED]>
>Sent: 3/8/05 12:34:50 AM
>To: "Struts Users Mailing List", "[EMAIL
> PROTECTED]"<[EMAIL PROTECTED]>
>Cc: "Corey Probst"<[EMAIL PROTECTED]>
>Subject: Re: why complicate? was: Eliminate Setup Actions
>
>
In what way?
-Original Message-
From: "Dakota Jack"<[EMAIL PROTECTED]>
Sent: 3/8/05 12:34:50 AM
To: "Struts Users Mailing List", "[EMAIL
PROTECTED]"<[EMAIL PROTECTED]>
Cc: "Corey Probst"<[EMAIL PROTECTED]>
In what way?
-Original Message-
From: "Dakota Jack"<[EMAIL PROTECTED]>
Sent: 3/8/05 12:34:50 AM
To: "Struts Users Mailing List", "[EMAIL
PROTECTED]"<[EMAIL PROTECTED]>
Cc: "Corey Probst"<[EMAIL PROTECTED]>
Isn't this all a bit contrary to the rightfully hallowed principles of
decoupling in OOP?
On Mon, 07 Mar 2005 22:56:23 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Corey Probst wrote:
> > Another thought, what about redirecting forwards?
>
> I'm glad you brought that up because I didn't
Corey Probst wrote:
Another thought, what about redirecting forwards?
I'm glad you brought that up because I didn't think of it, and wouldn't
have until after someone noticed it :)
I don't think there is anything that can be done about that, at least
not in the case where you redirect to a JSP.
actions can already have all the forwards you want.
On Mon, 7 Mar 2005 20:18:20 -0600, Corey Probst <[EMAIL PROTECTED]> wrote:
> I really like the idea of adding the *setup_definitions* (whatever
> they are eventually called) to the forward elements in struts-config.
> To me, this would be the m
I really like the idea of adding the *setup_definitions* (whatever
they are eventually called) to the forward elements in struts-config.
To me, this would be the most logical place to add them. This means
that they (the setup methods) would only be processed when it's 100%
sure that we are going
Hehe, I didn't know Ben was looking at introduction stuff on your site.
In light of that, I say ignore everything EXCEPT what Rick posted here
:) KISS, until you know you need something more.
I do think it spawned a very worth-wild exchange though, so good job
Ben! :) Who knows... if what I pu
Dakota Jack wrote the following on 3/7/2005 5:16 PM:
I am not sure what you mean by "page-centric", Rick. But, I don't
think you can use Struts in a "page-centric" way if you mean the way
Shale or JSF operate.
Sorry, I didn't mean by the way Shale or JSF operates (haven't even
looked at Shale y
Glad your on board :) I am going to work on it tonight, with a little
luck I can get at least a first iteration done and post in Bugzilla
tomorrow. Then we'll see if it passes muster for real :)
I know what you mean about keeping up with posts... I feel like I'm
constantly missing things :)
On Mon, 7 Mar 2005 16:07:34 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> 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 wo
Frank W. Zammetti wrote the following on 3/7/2005 4:07 PM:
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, (although, as I wrote that just now, I think
maybe makes more sense... pe
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 co
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 co
I think a simple approach is using tiles Controllers. They're WAY
simple. Having said that I might be over SIMPLIFIYING the problem
http://www.theserverside.com/articles/article.tss?l=Tiles101
On Mon, 07 Mar 2005 14:23:07 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Ben Taylor wrote the foll
Ben Taylor wrote the following on 3/5/2005 3:03 AM:
Hi,
Can anyone tell me if there is an easy way to put information
(required to populate drop down boxes using data from a db) in to the
request, without having to write a setup Action for each page as is
done here: http://www.reumann.net/struts/le
I just found this link which gives FAR more detail on Tiles
Controllers -->
http://www.theserverside.com/articles/article.tss?l=Tiles101
On Sat, 5 Mar 2005 13:15:44 -0600, Corey Probst <[EMAIL PROTECTED]> wrote:
> If your app is using tiles, take a look at Tile controllers.
>
> http://struts.apa
For anyone interested, I have a "Struts View" demo which that allows "dialogs"
to occur in Struts 1.3. This could work in Struts 1.2, but I haven't had the 3
minutes to write an extended RequestProcessor for current apps. Basically, a
dialog allows objects to persist across HTTP requests.
Pleas
LOL "dimplomatic" (???) -- This is a Freudian feast! LOL ///;-)
Once you really got going with "half-assed", Frank, I think I am up on
you on the scale today. ///;-) I actually have a lot of sympathy for
the attempt to compete with Micro$. They are clever as all get out.
However, I think th
Frank,
> 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
>
Frank,
> 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
>
> That would actually
> fulfill the goals I had. Would you find that difficult to manage?
No, surely not :-) I we were misunderstanding each other; actually you wrote
" I'm not sure about introducing a whole new collection of objects, and
management components to go along with it."
And I just re
> That would actually
> fulfill the goals I had. Would you find that difficult to manage?
No, surely not :-) I we were misunderstanding each other; actually you wrote
" I'm not sure about introducing a whole new collection of objects, and
management components to go along with it."
And I just re
I think, for me, all of this goes the opposite direction of where my
mind is going, that is, a more service-oriented approach.
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
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
6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the developer to
basically one setup per class, or forcing them to do some work that
Struts really should be doing...
If I were to add something like this to Strut
Really interesting stuff, Leon. By making data that normally is
static dynamic, you also do a lot more than is immediately evident.
This is very exciting stuff, in my opinion. I originally tried to do
this sort of thing with hot-deploy and classloaders. I am not sure
that is not a good solution
n file
> > notifyConfigurationFinished();
> >
> > it's absolutely simple, but works superb, we are using it to
> > reconfigure caches, switch databases switch legacy systems
> on and off.
> >
> > Is it IoC enough for you?:-)
> >
> > Regards
> &g
n file
> > notifyConfigurationFinished();
> >
> > it's absolutely simple, but works superb, we are using it to
> > reconfigure caches, switch databases switch legacy systems
> on and off.
> >
> > Is it IoC enough for you?:-)
> >
> > Regards
> &g
I mentioned Shale because of the whole prerender() idea that Craig
talked about in another reply to this thread. I didn't know enough to
specifically name the ViewController and prerender() methods though, I
just remembered the basic concepts :) I think that aspect of Shale (and
JSF too as I
I think that this is the "virtue" and the "vice", isn't it? JSF is
page-centric. It is essentially Swing on html. If you like Swing,
you might love Shale/JSF. That is not a criticism. I like Swing and
think that Shale/JSP is very interesting. Nothing like Struts and a
crime to call itself any
LOL This reminds me of the Greek guy in "My Big Fat Greek Wedding"
who attributes all ideas to Greeks. I think your idea is cool and was
cool when previously presented, but it not only is not but cannot be
part of Shale because of the basic structure of that framework. I
don't think that Shale o
Ben,
I don't want to bother raw Struts user's mailing list,
but I would like to introduce OzStruts again.
because all the Struts developers are struggling with this same issue again,
again and again.
I think this functionality must be prepared as part of web applicaiton
framework.
If you have op
using it to reconfigure
caches, switch databases switch legacy systems on and off.
Is it IoC enough for you?:-)
Regards
Leon
-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate S
I have no interest in Shale personally. And, I don't think this idea
has been bounced around in that regard. The only interest I have in
this in a request driven web MVC setup, which Shale (JSF) is not.
Shale is an event driven framework like Echo and Tapestry and is
essentially an attempt to ma
...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 "b
on: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 6. März 2005 00:14
> An: Struts Users Mailing List
> Betreff: Re: Eliminate Setup Actions
>
> Sure, that would work. But, then you are limiting the
> developer to basically one setup per class, or forcing the
on: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 6. März 2005 00:14
> An: Struts Users Mailing List
> Betreff: Re: Eliminate Setup Actions
>
> Sure, that would work. But, then you are limiting the
> developer to basically one setup per class, or forcing the
On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Then again, I know *someone* is going to point out that Shale (or I
> guess JSF generically?) already has this notion ingrained in it.
But of course! :-)
In Shale, a ViewController bean (pretty much the equivalen
Sure, that would work. But, then you are limiting the developer to
basically one setup per class, or forcing them to do some work that
Struts really should be doing...
If I were to add something like this to Struts (and I have enough
interest in this idea that I'd love to persue it, assuming t
> ... I figured you'd specify
> the class and method to call, although even easier would be
> to write an actual SetupAction class, or something along
> those lines, with a known interface that all these classes
> would have to implement, then you would just specify the
> class and Struts wou
> ... I figured you'd specify
> the class and method to call, although even easier would be
> to write an actual SetupAction class, or something along
> those lines, with a known interface that all these classes
> would have to implement, then you would just specify the
> class and Struts wou
I for one would be interested in such a thing. I was starting to think
about how to do this in a generic enough way too...
I was actually thinking of doing it declaratively, i.e., for each Action
mapping you could specify a list of setup methods to call, and Struts
would go ahead and do that r
I think this solution is "the bomb". I once suggested a generic
solution like this for Struts called StrutsState. No one was much
interested, so I just built it for my own work. It is so helpful that
I cannot express my gratitude toward myself to myself. ///;-)
On Sat, 05 Mar 2005 14:27:08 -0
Someone else made some good suggestions about listeners and plugins.
These will work well if the dropdown contents are truly static.
If however it might be the kind of values that you want to make sure are
up-to-date, i.e., read from a database maybe...
Then one simple solution is create yourse
If your app is using tiles, take a look at Tile controllers.
http://struts.apache.org/api/org/apache/struts/tiles/Controller.html
The controller will get called right before rendering the jsp,
allowing you to put your info into the request.
Corey
You could populate static combo boxes with data stored as application
scope attributes that are set at app startup by either a
ServletContextListener or a Struts PlugIn (those attributes will be
available to any JSP in the app).
Erik
Ben Taylor wrote:
Hi,
Can anyone tell me if there is an easy
turday, March 05, 2005 12:03 AM
Subject: Eliminate Setup Actions
Hi,
Can anyone tell me if there is an easy way to put information
(required to populate drop down boxes using data from a db) in to the
request, without having to write a setup Action for each page as is
done here: http://www.reum
Hi,
Can anyone tell me if there is an easy way to put information
(required to populate drop down boxes using data from a db) in to the
request, without having to write a setup Action for each page as is
done here: http://www.reumann.net/struts/lesson2/step9.do .
Thank you for any help!
---
78 matches
Mail list logo
