Re: Struts Shale v1.0.2 Quality
+1 (non binding) for Alpha On 3/23/06, Gary VanMatre [EMAIL PROTECTED] wrote: +1 for Alpha as well. Outside of the one known issue with the sql-browser application, it looks good. Nice work Wendy. Gary -- Original message -- From: Wendy Smoak [EMAIL PROTECTED] After correcting packaging problems with the Shale 1.0.1 test build, and following the release plan which is available on the Wiki, http://wiki.apache.org/struts/ShaleRelease102 the Struts Shale v1.0.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/shale/v1.0.2/ including checksums and signatures, which may be verified against http://www.apache.org/dist/struts/KEYS . Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Alpha quality, due to Shale's dependence on a snapshot of Standalone Tiles. -- Wendy Smoak - 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]
FW: Re: Struts shale questions / modifications
--- Please Note: This is a conv. I had with Craig and I cannot
access bugzilla ATM, so I'm forwarding this to the full list with
attachments.
--- This email has my first email fo Craig, his reply and at last my
new reply to both Craig and List.
/ First Email /
Dear Craig:
I've been hacking shale a bit, mainly beacuse some needs our
organization
has regarding the default implementation of Dialog under base packages.
As a background, we have been taking a look and using shale in some
small
applications, but we've been thinking about hacking shale. To make you
understand our intentions, here is a small briefing:
What we really want is to have *ALL* our navigation (except ajax) go
throught dialogs. To achieve this, we have implemented a default
outcome
(transition) in all dialogs except the root one. That way, when you're
navigating through any dialog, at any time, you can ask the root dialog
(the menu) to start another one. The root dialog, which can be
considered
as the application menu, has all Use Cases as subdialogs. The default
target is (we're still thinking about it) always an exit (end) point for
all of the
sub-dialogs, so when you ask something that the dialog cannot
understand, it's
transfered to his parent dialog.
Using this aproach, we can start almost every dialog (except the root
one) in
any part/dialog of our application.
We have been thinking about implementing our navigation handler, but
you
(your team) has done a great effort with Shale, and almost all the
features we
want, except the one mentioned above are already implemented, so... why
reinventing the wheel?
My main question is, is there any way, without hacking deep on Shale
(our tests
only add 4 lines of code to the original Shale) to change the default
implementation
of Dialog?
So far, I've been added the following code to Shale navigation handler
private State transition(Status status, State state, String outcome)
method:
private static final String DEFAULT_TRANSITION = default;
private State transition(Status status, State state, String outcome) {
-- Line 526
if (transition == null) {
transition =
state.getDialog().findTransition(DEFAULT_TRANSITION);
if (transition == null) {
log.debug(No default transition found!); //@todo: I18N
}
}
--- line 527
}
Maybe you think this is useless but I've coded a small bean framework
that can
handle with this of aproach nicely, but I really need that default
transition on
dialogs to get it working with Shale.
I think it would be better to supply Shale with our own implementation
of Dialog,
just extending Shale's one and adding the above modifications to
findTransition method,
but AFAIK is not possible to do that, unless hacking inside at context
startup and
changeing the Dialogs found on it. I think it'd be really stupid because
adding just 2 lines
of code (plus debug code) will require much more effort than being able
to supply
Shale our own Dialog Impls.
I know Shale is still under development, and there are a lot of things
that are going to be
changed, but we find it stable enough to use it on several projects.
Can you please, give me some advise about how to perform this hack, or
just some
pointers about where to ask for more information?
/* Craig Reply */
Juan,
Your ideas are certainly interesting ones. Unfortunately there is no
current mechanism to specify your own custom implementation of
DialogNavigationHandler ... that is a worthwhile enhancement request
all by itself. As to the basic idea of your change, I personally get
a little nervous about magic behaviors (such as going to a
particular place when an unknown outcome is specified), but I can
certainly see how it works for your use case.
The best place to discuss Shale is on the Struts user mailing list
(for user-related questions) and on the Struts developer list (for
questions about changes to the code, like this one). You can find
subscription information at [1] if you are not already subscribed. To
file enhancemnent requests or bug reports in our issue tracking system
at [2].
Could you do me a favor and file an enhancement request for the allow
the developer to provide their own custom DialogNavigationHandler
implementation? I'm currently travelling, and am likely to forget
about it along the way :-).
Thank you very much in advance, and please forgive me if this is
not the
right way of
contact Shale dev-team.
PD: Excuse me about my English, since it's not my natural language.
You do not need to apologize ... your English is very understandable.
/** My Final Reply to the list **/
Hi Craig (and devlist users),
I'm writting to you but I'm sending this
RE: [shale] Re: Struts Shale
I've been watching this conversation from the sidelines. I see in the email
description below the purpose of the new Dialog object:
1.
To me, the lifetime of the state information is the key
distinguishing feature to this gadget -- so if we don't like
dialog then maybe some name around that idea would be more
appropriate.
Are there any other things that make this object unique? Are there current
examples of how it would be set up or used? I was thinking about how this idea
would be implemented if #1 was the only requirement and came up with the
following. I hope it adds value to the discussion.
I took a look at the DialogController Shale source and it seems that the
methods are defined via code but the goal is essentially to replicate session
at a smaller level. If this is the only case (and I may be way off base here)
why not introduce a mock session object so that the actions/etc are none the
wiser. The end of a dialog would be defined by some final action that would
clean up the session so the Cancel/Complete wouldn't matter. Here's some
pseudo-code to show what I was thinking:
// I have no clue on Shale config so this is basically a struts example
that would need to be modified for the equivalents in Shale
action
path=/action/rates/GetAutoRateQuote
type=com.xxx.xxx.StartAutoRateQuote
name=formName
dialogName=dialogName /* THIS WOULD BE HOW MULTIPLE ACTIONS CAN
BE GROUPED AS A DIALOG */
validate=false
forward name=success path=/jsp/path/thejsp.jsp/
/action
At the server you check if a dialogName exists, if so then it's a dialog. If
that dialog is not currently in existence, then create a session space for it:
if(session.getActiveDialogs().get(dialogName)==null){ //no session with
that name exists
webSession = session; // Just to illustrate that this is the
REAL session
dialogSession = new dialogSession(session); // session is
passed so the user can use the same session life-cycle methods on a mini scale
and it has a reference to the real session object as needed to look up
objects. If it is not found in dialog session it can then check real session
webSession.set(DIALOGSESSION+_+dialogName, dialogSession);
//Give the dialog session a spot in the real session
}
//The call to the action/dialog in this case would pass the
dialogSession instead of the real session in this case. So a call to
session.invalidate() would just remove the dialog from the real session.
Maybe there are other goals for dialog that I am not aware of that this would
not work for. I think the above would essentially make a struts app a series
of dialogs for the most part except probably the login/logout and other
universal functions. Of course the naming above would be confusing as hell so
you'd probably want to use better names in the execute type method so the
user doesn't think they're working with a session. Maybe a name like Scope,
so you're passed a scope as part of the execute method to make it clear that
any of the work you do is limited to whatever the configuration scope is
(handled as part of config).
Please advise how this may or may not suit your needs. I hope I'm not 100%
off-base here.
Regards...djsuarez
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 5:04 AM
To: Struts Developers List
Subject: Re: [shale] Re: Struts Shale
It would be a good idea to name both the set and the member at the same time.
Some suggestions
* Activity and Task
* Circuit and Gate
* Track and Step
* Process and Node
which leads to conjugations like
* ActivityState
* CircuitState
* TrackState
* ProcessState
If this were Friday, I might add
* Ripple and Domino :)
-Ted.
On Thu, 20 Jan 2005 05:07:03 +, Duncan Mills wrote:
In the past I've been around this merry-go-round on another
Controller implementation, the end result of that painful exercise
in semantics was the following:
1) An activity - a single node on the flow - display a page, send
an email, execute this code etc.
2) A Process - a group of activities, logically of course this
process itself can be nested as an activity in a flow.
So this is why I tend to use process, it's also neutral enough to
(I think) co-exist with the scope's we're used to. Another factor
here is that using an overloaded term (like dialog) is acceptable
to a native English speaker but can be confusing if English is not
your primary language, this would also rule out a term like Wizard.
Duncan
Craig McClanahan wrote:
The only problem I have with wizard is that it implies a serial
forwards-backwards flow. I can see cases for dialogs :-) with
branches in them. (It's the same reason I took standard next
and previous methods back out of the API ... the concept
doesn't always
Re: [shale] Re: Struts Shale
What about a UseCase, who keeps track of the state of the (dialog|conversation|navigation) with the user? No need to separate in Action (behavior of a object) and ActionForm (state of a object). Just an UseCase (oder MongoMongoBanana) to invoke its methods via reflection (a la DispatchAction). Bernardo Antonio Buffa Colomé [EMAIL PROTECTED] The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
What about a UseCase, who keeps track of the state of the (dialog|conversation|navigation) with the user? No need to separate in Action (behavior of a object) and ActionForm (state of a object). Just an UseCase (oder MongoMongoBanana) to invoke its methods via reflection (a la DispatchAction). Bernardo Antonio Buffa Colomé [EMAIL PROTECTED] The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
Not MD_20_20_State? LOL. Anyway, I like this suggestion on any day of the week. I think naming here is very, very important, by the way. So much difficulty is caused by bad naming. Jack On Thu, 20 Jan 2005 06:04:23 -0500, Ted Husted [EMAIL PROTECTED] wrote: It would be a good idea to name both the set and the member at the same time. Some suggestions * Activity and Task * Circuit and Gate * Track and Step * Process and Node which leads to conjugations like * ActivityState * CircuitState * TrackState * ProcessState If this were Friday, I might add * Ripple and Domino :) -Ted. On Thu, 20 Jan 2005 05:07:03 +, Duncan Mills wrote: In the past I've been around this merry-go-round on another Controller implementation, the end result of that painful exercise in semantics was the following: 1) An activity - a single node on the flow - display a page, send an email, execute this code etc. 2) A Process - a group of activities, logically of course this process itself can be nested as an activity in a flow. So this is why I tend to use process, it's also neutral enough to (I think) co-exist with the scope's we're used to. Another factor here is that using an overloaded term (like dialog) is acceptable to a native English speaker but can be confusing if English is not your primary language, this would also rule out a term like Wizard. Duncan Craig McClanahan wrote: The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
On Wed, 19 Jan 2005 22:12:58 -0800, Dakota Jack [EMAIL PROTECTED] wrote: ClientState? ViewState? What is the lifetime? If the lifetime = x, I would suggest XState. X ~= longer than a request, shorter than a session :-) Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
Craig Wrote: My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Craig I'm curious, could a dialog, or whatever it ends up being called, have the ability to create sub dialogs? These sub-dialogs could be put into a sandbox that the parent deletes upon exit. Keeping the sub dialogs in a collection of some sort would allow for multiple paralell dialogs. Having a master dialor for the session that is always there would allow for even the top-level dialogs to be removed and none of them would have to know their own names anymore. Right? Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
On Thu, 20 Jan 2005 11:54:06 -0600, Michael Rasmussen [EMAIL PROTECTED] wrote: Craig Wrote: My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Craig I'm curious, could a dialog, or whatever it ends up being called, have the ability to create sub dialogs? These sub-dialogs could be put into a sandbox that the parent deletes upon exit. Or even a stack, for that matter, so you can have arbitrary nesting. (Although that wouldn't deal with the multiple-window case where you might have a separate dialog going in each.) Keeping the sub dialogs in a collection of some sort would allow for multiple paralell dialogs. Having a master dialor for the session that is always there would allow for even the top-level dialogs to be removed and none of them would have to know their own names anymore. Right? As it's currently implemented, the dialog comes into existence (and gets stored in session scope) as a side effect of being loaded as a managed bean. Therefore, right now, there's no notification to the framework to put that very first dialog into any sort of collection. That probably needs to change in order to deal with this particular issue. Duncan had a suggestion related to that, of using the plugin capability on the NavigationHandler to recognize when you are navigating to a dialog for the first time. That bears some investigation as well. Michael Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
snip Craig Wrote: My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Craig /snip In my experience, this sort of program, app, or whatever you want to call it, is better stored in application scope. That way there are no limits to the algorithms you can foster. Jack -- -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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: [shale] Re: Struts Shale
We call it an activity on my current project. Basically, all activities are begun from a tabbed main menu called The Launchpad, and when the user clicks on any one of the available activities, they are taken through a few defined steps, some dynamic (forward pages based on product from the db), and some are wizard like. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org; Sean Schofield [EMAIL PROTECTED] Cc: Hubert Rabago [EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 7:37 PM Subject: Re: [shale] Re: Struts Shale The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
In the past I've been around this merry-go-round on another Controller implementation, the end result of that painful exercise in semantics was the following: 1) An activity - a single node on the flow - display a page, send an email, execute this code etc. 2) A Process - a group of activities, logically of course this process itself can be nested as an activity in a flow. So this is why I tend to use process, it's also neutral enough to (I think) co-exist with the scope's we're used to. Another factor here is that using an overloaded term (like dialog) is acceptable to a native English speaker but can be confusing if English is not your primary language, this would also rule out a term like Wizard. Duncan Craig McClanahan wrote: The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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: [shale] Re: Struts Shale
ClientState? ViewState? What is the lifetime? If the lifetime = x, I would suggest XState. Jack On Wed, 19 Jan 2005 16:37:58 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: The only problem I have with wizard is that it implies a serial forwards-backwards flow. I can see cases for dialogs :-) with branches in them. (It's the same reason I took standard next and previous methods back out of the API ... the concept doesn't always apply. To me, the lifetime of the state information is the key distinguishing feature to this gadget -- so if we don't like dialog then maybe some name around that idea would be more appropriate. Craig On Tue, 18 Jan 2005 15:16:16 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - 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] -- -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Re: Struts Shale
Hello Craig, I see your point and I think you are right but there is one disadvantage leaving the coding of the prev and next button up to the developer. Most of the times the developers do not clean up the session when using a dialogflow or a pageflow. This leaves a lot of garbage in the session bloating it up. So if the framwork could provide a mechanism for making this easier I think the whole application will benefit from it. This framework could be seperate from the actual dialogcontroller so only those people can use it that need it or want to benefit from it. My thinking is this is infrastructure so it should be covered by the framework and not on a per application level. Another side effect of this could be the possibility to provide a mean to navigate backwards using the standard browser back button. Craig McClanahan wrote: On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer [EMAIL PROTECTED] wrote: Hello, not sure if I'm addressing the right person, got your mail off the myfaces mailing list. If addressing is wrong ignore this mail. I'm the right person. To the point I read your proposal about struts shale and jsf and find your implementation very interesting and am looking forward to a hopefully soon release. I have a few suggestions which and am wondering where I can introduce them to shale. I don't want to edit the wiki directly and I didn't find a comment section is there a discussion list? Since Shale is part of the Struts project, the best discussion list is the Struts developer list (to subscribe, send an empty message to [EMAIL PROTECTED]). Then, to help people sort conversations, it would be common to put [shale] in the message subject, so that people who are not interested could easily filter it out. Anyhow here it goes: I especially like the idea of a dialogscope. The thing which I would find interesting is to define the flow of a dialog in some config file (preferrably xml) and being able to provide a back functionality in addition to the enter, exit and cancel in the dialogcontroller. Interesting ... I had next() and previous() methods in my original design for this API. This would make creating wizard like dialogs very easy and provide a way to navigate through the dialog in both directions. The reasons I don't have next() and previous() at the moment are as follows: * Wizards tend to have a sequential flow (forwards and backwards) but that isn't the only kind of dialog that needs to be supported. The methods would go unused in some cases. * Manually implementing next and previous functionality (as I did in the use cases example app) is so easy to do that it's hard to see much benefit from having the methods directly implemented. * A generic next or previous method would have to be aware of all the possible logical outcomes, and this list would have to be updated every time a new step was added. In the current approach an event handler only has to know the outcome ot get to the adjacent view, and isn't affected when new steps are added (unless it is adjacent). Does that make sense? Taking the synchronization token pattern in account it might even be possible to provide the same data when the user presses the browser back button. I think this is going to require some assistance from the state saving machinery that JSF provides, but it would be interesting. It might also be that the user still expects the state information to be the most current state, just like they would get from a regular previous button. The advantage of a flow control is that the session can be cleaned fairly easy when skipping from one dialog to the other and information is not unnessecarly stored. My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Regards Stefan Langer Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
No one is suggesting that Shale is off-topic. Using these types of remarks in a subject line is an established courtesy on higher-traffic lists. The Shale codebase lives here, and Struts Dev is the preferred list for posts regarding Struts Shale. 'nuff said. -Ted. On Tue, 18 Jan 2005 06:48:37 -0800, Dakota Jack wrote: I have to smile at the suggestion that [shale] will be a substitute for OT so that Struts developers will not be burdened by these JSF discussions. That is exactly the sentiment of Rod Johnson in J2EE Development without EJB. I also agree. What could be more ironic than a proposed future of a project being clearly OT? LOL Talk about 1984! Jack On Tue, 18 Jan 2005 09:25:16 +0100, Stefan Langer [EMAIL PROTECTED] wrote: Hello Craig, I see your point and I think you are right but there is one disadvantage leaving the coding of the prev and next button up to the developer. Most of the times the developers do not clean up the session when using a dialogflow or a pageflow. This leaves a lot of garbage in the session bloating it up. So if the framwork could provide a mechanism for making this easier I think the whole application will benefit from it. This framework could be seperate from the actual dialogcontroller so only those people can use it that need it or want to benefit from it. My thinking is this is infrastructure so it should be covered by the framework and not on a per application level. Another side effect of this could be the possibility to provide a mean to navigate backwards using the standard browser back button. Craig McClanahan wrote: On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer [EMAIL PROTECTED] wrote: Hello, not sure if I'm addressing the right person, got your mail off the myfaces mailing list. If addressing is wrong ignore this mail. I'm the right person. To the point I read your proposal about struts shale and jsf and find your implementation very interesting and am looking forward to a hopefully soon release. I have a few suggestions which and am wondering where I can introduce them to shale. I don't want to edit the wiki directly and I didn't find a comment section is there a discussion list? Since Shale is part of the Struts project, the best discussion list is the Struts developer list (to subscribe, send an empty message to [EMAIL PROTECTED]). Then, to help people sort conversations, it would be common to put [shale] in the message subject, so that people who are not interested could easily filter it out. Anyhow here it goes: I especially like the idea of a dialogscope. The thing which I would find interesting is to define the flow of a dialog in some config file (preferrably xml) and being able to provide a back functionality in addition to the enter, exit and cancel in the dialogcontroller. Interesting ... I had next() and previous() methods in my original design for this API. This would make creating wizard like dialogs very easy and provide a way to navigate through the dialog in both directions. The reasons I don't have next() and previous() at the moment are as follows: * Wizards tend to have a sequential flow (forwards and backwards) but that isn't the only kind of dialog that needs to be supported. The methods would go unused in some cases. * Manually implementing next and previous functionality (as I did in the use cases example app) is so easy to do that it's hard to see much benefit from having the methods directly implemented. * A generic next or previous method would have to be aware of all the possible logical outcomes, and this list would have to be updated every time a new step was added. In the current approach an event handler only has to know the outcome ot get to the adjacent view, and isn't affected when new steps are added (unless it is adjacent). Does that make sense? Taking the synchronization token pattern in account it might even be possible to provide the same data when the user presses the browser back button. I think this is going to require some assistance from the state saving machinery that JSF provides, but it would be interesting. It might also be that the user still expects the state information to be the most current state, just like they would get from a regular previous button. The advantage of a flow control is that the session can be cleaned fairly easy when skipping from one dialog to the other and information is not unnessecarly stored. My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Regards Stefan Langer Craig
Re: [shale] Re: Struts Shale
+1, In the normal case nested process scope should be automatically cleaned up, however, in order for that to be useful, there also has to be sufficient metadata defining the process to map return state from the private process (dialog) scope to the outer scope automatically, plus of course trigger points for code if the developer can't express the desired mapping solely in metadata Duncan Stefan Langer wrote: Hello Craig, I see your point and I think you are right but there is one disadvantage leaving the coding of the prev and next button up to the developer. Most of the times the developers do not clean up the session when using a dialogflow or a pageflow. This leaves a lot of garbage in the session bloating it up. So if the framwork could provide a mechanism for making this easier I think the whole application will benefit from it. This framework could be seperate from the actual dialogcontroller so only those people can use it that need it or want to benefit from it. My thinking is this is infrastructure so it should be covered by the framework and not on a per application level. Another side effect of this could be the possibility to provide a mean to navigate backwards using the standard browser back button. Craig McClanahan wrote: On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer [EMAIL PROTECTED] wrote: Hello, not sure if I'm addressing the right person, got your mail off the myfaces mailing list. If addressing is wrong ignore this mail. I'm the right person. To the point I read your proposal about struts shale and jsf and find your implementation very interesting and am looking forward to a hopefully soon release. I have a few suggestions which and am wondering where I can introduce them to shale. I don't want to edit the wiki directly and I didn't find a comment section is there a discussion list? Since Shale is part of the Struts project, the best discussion list is the Struts developer list (to subscribe, send an empty message to [EMAIL PROTECTED]). Then, to help people sort conversations, it would be common to put [shale] in the message subject, so that people who are not interested could easily filter it out. Anyhow here it goes: I especially like the idea of a dialogscope. The thing which I would find interesting is to define the flow of a dialog in some config file (preferrably xml) and being able to provide a back functionality in addition to the enter, exit and cancel in the dialogcontroller. Interesting ... I had next() and previous() methods in my original design for this API. This would make creating wizard like dialogs very easy and provide a way to navigate through the dialog in both directions. The reasons I don't have next() and previous() at the moment are as follows: * Wizards tend to have a sequential flow (forwards and backwards) but that isn't the only kind of dialog that needs to be supported. The methods would go unused in some cases. * Manually implementing next and previous functionality (as I did in the use cases example app) is so easy to do that it's hard to see much benefit from having the methods directly implemented. * A generic next or previous method would have to be aware of all the possible logical outcomes, and this list would have to be updated every time a new step was added. In the current approach an event handler only has to know the outcome ot get to the adjacent view, and isn't affected when new steps are added (unless it is adjacent). Does that make sense? Taking the synchronization token pattern in account it might even be possible to provide the same data when the user presses the browser back button. I think this is going to require some assistance from the state saving machinery that JSF provides, but it would be interesting. It might also be that the user still expects the state information to be the most current state, just like they would get from a regular previous button. The advantage of a flow control is that the session can be cleaned fairly easy when skipping from one dialog to the other and information is not unnessecarly stored. My current thinking is that we want the ability to have more than one active dialog, so you can push from one dialog to another, then pop back out. That's why I made it the dialog's responsibility to clean itself up. I don't like the fact that the dialog has to know the attribute name it is stored under (in session scope), but haven't figured out a way around it yet. Regards Stefan Langer 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: [shale] Re: Struts Shale
On Tue, 18 Jan 2005 17:14:56 +, Duncan Mills [EMAIL PROTECTED] wrote: +1, In the normal case nested process scope should be automatically cleaned up, however, in order for that to be useful, there also has to be sufficient metadata defining the process to map return state from the private process (dialog) scope to the outer scope automatically, plus of course trigger points for code if the developer can't express the desired mapping solely in metadata Duncan +1 as well, as long as we still want the ability to have more than one dialog active for a given user (both for nesting, but also for multiple frames/windows). Currently, a DialogController is responsible for removing itself from session scope in one of its exit methods (adding it initially is taken care of by the managed beans processing), which creates an ugly need to know what attribute key it was stored under. A plugin NavigationHandler is worth looking at (along the lines that Duncan suggested); however, this is likely to mean the need for an externally defined configuration file -- the standard DTD doesn't provide any extendability in this particular area. Regarding the name dialog (which Duncan also raised in his original post); I'm open to alternatives, but could not think of anything that was really more evocative. I've heard some people refer to the general idea as transaction scope, but IMHO that doesn't really match up to what you might want to do in one of these things. Craig Stefan Langer wrote: Hello Craig, I see your point and I think you are right but there is one disadvantage leaving the coding of the prev and next button up to the developer. Most of the times the developers do not clean up the session when using a dialogflow or a pageflow. This leaves a lot of garbage in the session bloating it up. So if the framwork could provide a mechanism for making this easier I think the whole application will benefit from it. This framework could be seperate from the actual dialogcontroller so only those people can use it that need it or want to benefit from it. My thinking is this is infrastructure so it should be covered by the framework and not on a per application level. Another side effect of this could be the possibility to provide a mean to navigate backwards using the standard browser back button. Craig McClanahan wrote: On Fri, 14 Jan 2005 09:27:51 +0100, Stefan Langer [EMAIL PROTECTED] wrote: Hello, not sure if I'm addressing the right person, got your mail off the myfaces mailing list. If addressing is wrong ignore this mail. I'm the right person. To the point I read your proposal about struts shale and jsf and find your implementation very interesting and am looking forward to a hopefully soon release. I have a few suggestions which and am wondering where I can introduce them to shale. I don't want to edit the wiki directly and I didn't find a comment section is there a discussion list? Since Shale is part of the Struts project, the best discussion list is the Struts developer list (to subscribe, send an empty message to [EMAIL PROTECTED]). Then, to help people sort conversations, it would be common to put [shale] in the message subject, so that people who are not interested could easily filter it out. Anyhow here it goes: I especially like the idea of a dialogscope. The thing which I would find interesting is to define the flow of a dialog in some config file (preferrably xml) and being able to provide a back functionality in addition to the enter, exit and cancel in the dialogcontroller. Interesting ... I had next() and previous() methods in my original design for this API. This would make creating wizard like dialogs very easy and provide a way to navigate through the dialog in both directions. The reasons I don't have next() and previous() at the moment are as follows: * Wizards tend to have a sequential flow (forwards and backwards) but that isn't the only kind of dialog that needs to be supported. The methods would go unused in some cases. * Manually implementing next and previous functionality (as I did in the use cases example app) is so easy to do that it's hard to see much benefit from having the methods directly implemented. * A generic next or previous method would have to be aware of all the possible logical outcomes, and this list would have to be updated every time a new step was added. In the current approach an event handler only has to know the outcome ot get to the adjacent view, and isn't affected when new steps are added (unless it is adjacent). Does that make sense? Taking the synchronization token pattern in account it might even be possible to provide the same data when the user presses the browser back button. I think this is going to require some assistance from the state
Re: [shale] Re: Struts Shale
Regarding the name dialog (which Duncan also raised in his original post); I'm open to alternatives, but could not think of anything that was really more evocative. I've heard some people refer to the general idea as transaction scope, but IMHO that doesn't really match up to what you might want to do in one of these things. What about conversation? I think I've heard that one thrown out there before. Craig sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
On Tue, 18 Jan 2005 12:41:35 -0500, Sean Schofield [EMAIL PROTECTED] wrote: Regarding the name dialog (which Duncan also raised in his original post); I'm open to alternatives, but could not think of anything that was really more evocative. I've heard some people refer to the general idea as transaction scope, but IMHO that doesn't really match up to what you might want to do in one of these things. What about conversation? I think I've heard that one thrown out there before. I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? Craig sean Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
Duncan Mills seems to characterize this as PrivateProcess. Something like that seems far more didactic and helpful to me than something it really is not, like Dialogue or Conversation. My suggestion is that the name reflect precisely what it is. Jack On Tue, 18 Jan 2005 13:10:54 -0600, Hubert Rabago [EMAIL PROTECTED] wrote: On Tue, 18 Jan 2005 12:41:35 -0500, Sean Schofield [EMAIL PROTECTED] wrote: Regarding the name dialog (which Duncan also raised in his original post); I'm open to alternatives, but could not think of anything that was really more evocative. I've heard some people refer to the general idea as transaction scope, but IMHO that doesn't really match up to what you might want to do in one of these things. What about conversation? I think I've heard that one thrown out there before. I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? Craig sean Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
Dakota Jack [EMAIL PROTECTED] wrote: Duncan Mills seems to characterize this as PrivateProcess. Something like that seems far more didactic and helpful to me than something it really is not, like Dialogue or Conversation. My suggestion is that the name reflect precisely what it is. Perhaps DataCollectionProcess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Re: Struts Shale
I almost suggested the same thing: conversation. Its length, though, could be unfriendly. ConversationController. What about dialogue with the ue at the end? What about wizard? This is what we call our own custom solution that we're using now. Wizard generally implies a guided series of steps where you can go forwards and backwards (at least to me it does.) sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
How could there be a reason not to do this? (This is not a rhetorical question.) Jack On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. What if a component based presentation solution could be found that built on the current features of struts and only focused on the view layer? Struts already has a flavor of managed beans, converters, error messages, localization, actions and declarative navigation rules. JSF provides all of these things in addition. I think it would be interesting to see a solution that was built for struts only focusing on rendering the view but not specifically tied to a single view solution. 1) Restore View Use a custom Request Processor to load a view tree in request scope. The view id could be a simple attribute that was associated with an extended ActionMapping. The view id could be associated with each struts action. The composition of a presentation fragment could be build from a XML source. The XML definitions could define display elements that could act as a container or a component. The definition could support inheritance and composition. Each visual element could be associated with a model class much the same way the action is linked in the struts config. The metadata could be loaded/digested and references fixed up at startup using a plug-in. The resources stored in application scope. 2) Apply Request Values Struts already handle the population of the form bean with values form the request. It handles some data conversion. A system to define unique names for a reusable component mapped into the form bean would be needed. JSF uses at component id which is a name qualified by the containment in the component tree. 3) Process Validation - Struts already provides a declarative validation mechanism. 4) Update Model Values, Invoke Application - A custom view controller could delegate to all the models in the component tree. The view controller, like the LookupDispatchAction and DispatchAction, would need to have a strategy of mapping command to methods or command classes. The component tree would already be staged in request scope from the request processor. The view controller could use the static view definition and create instances of model classes associated with each view element. The controller would need to broadcast too all the model classes. 5) Render Response The action could forward to the view component. The view component would use the component tree metadata and simple helper classes to render the view. The view helper would enumerate metadata and render the view. They could be use in JSP, Custom JSP tags or
Re: Struts Shale
I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. Jacki On Thu, 28 Oct 2004 14:06:32 -0500, Joe Germuska [EMAIL PROTECTED] wrote: The focus of the visual component base solution would be to create a XML definition, backed beans, and an abstract factory/ cache to manage the resources. Create a view controller or action class that knows how to use the metadata to manage corresponding model classes. And view helpers that would encapsulate the call back to the models when generating a presentation. It's not as sexy as faces? Thanks for listening ti What you describe still sounds like it's essentially rewriting Faces-type functionality. I think I'm warming up to Craig's point. The only reason we shouldn't use JSF is if we don't like the processing model it provides. If we like the processing model it provides, we shouldn't go to the trouble to rewrite it. Folks who want to do that can work on the MyFaces implementation instead. My JSF experience is still limited to reading about it. I find it pretty interesting. I've read some commentary that pegs it as overkill, but haven't reached that conclusion myself. I'd be better off talking about it if I'd used it more. The point being that JSF stakes out a lot of territory for the view-side of the equation. Craig's deep familiarity with it makes it a natural way for him to envision the view-controller side of Shale. If people think it's not a good solution to the view-controller side, then they should articulate why -- and even if the why is just i'd rather not buy into JSF yet, then they should come up with an alternate description of the view controller's responsibilities. Then people can make a choice based on how it works rather than what its called. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features outside of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: 28. oktober 2004 19:40 To: Dakota Jack; Struts Developers List Subject: Re: Struts Shale I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features outside of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: 28. oktober 2004 19:40 To: Dakota Jack; Struts Developers List Subject: Re: Struts Shale I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 15:27:49 -0700, Dakota Jack [EMAIL PROTECTED] wrote: I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. A particular implementation of JSF, or a particular view technology in general? You don't have to worry about the former ... we'd be coding solely to JSF standard APIs, so you can use the JSF RI, MyFaces (once they fix a few outstanding bugs that mess up struts-faces too :-), or anyone else's conforming implementation. Choosing to rely or not rely on JSF's request processing lifecycle has huge impact on the design of Shale ... basically for everything that JSF already does that we want to keep, we'd have to define our own abstraction and then enforce that contract on any other technology. The simplest example is navigating from one page to another -- if you can't assume JSF underneath, then ViewController (or something) needs some additional API to do that. Regarding JSF information, I have read and can vouch for Hans Bergsten's and David Geary's JSF books. I haven't had time to read some of the others, but I've met some of the authors and it seems likely that they'll be high quality as well. A good starting bookmark for your browsing pleasure is http://jsfcentral.com, which has links to lots and lots of resources about JSF. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. I sure hope it doesn't take us 1-2 years, but with our track record I'd be pretty foolish to make any promises at this point :-). Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? 99.9% of the issue is configuration -- getting the right JARs and configuration files in the right place. In that sense its not really different than any other JAR that might be included in the webapp or installed in the container. You just need to get all the moving parts where they belong. And use C-L 1.0.4 or later, of course, because there were some critical bugfixes. Struts 1.x has used C-L from the very beginning of its existence, and we've been satisfied with it. Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? There are a lot of potential customers that have existing environments based on things like Log4J, and those folks would be really (and justifiably) irritated to be required to configure two logging systems. Regards, \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
At 3:27 PM -0700 10/28/04, Dakota Jack wrote: I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. Particular implementation of what? View renderer? JSF can use Velocity to render its views, so it's not tied to JSP as the implementation of a view renderer. View controller? JSF is an API, so you aren't tied to the reference implementation. In fact, there is an Apache incubator project (MyFaces) to build an alternative implementation: http://incubator.apache.org/projects/myfaces.html Of course, there is no more generalized view controller API right now. Craig's point is that it would be substantially reinventing the wheel to design yet another API and implementation when JSF seems to address all the bases. Craig is starting from his knowledge of JSF and proscribing it as a facility for providing a lot of functionality to Shale. If anyone cares to start from the other side and describe the functionality Shale needs, and finds that they don't end up essentially describing JSF, then we'd have something to choose between. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Craig is starting from his knowledge of JSF and proscribing it as a facility for providing a lot of functionality to Shale. er... prescribing. Sorry. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. 2.5 Functionality Not Included In Struts 2.0 Core Would any view packages be bundled with the 2.x core, or would the core be the Application controller and interfaces for the Dialog and View controllers (and any implementation-independent utilities). 2.5 Functionality Not Included In Struts 2.0 Core Since client-side validation is mentioned, are we leaving the door open for server-side validation? Perhaps as an abstract link in the request processing chain? Would there be an interface for the Application Controller? [New topic] 2.6 Unit Tests Would it be all right if I contributed some unit tests to the codebase accompanying the proposal? I realize that everything is subject to change, and the tests would have be resynched with any changes, but I'm up for that :) Obviously, the tests would not be much at this point, but I want to be sure we start out on the right foot. 3.8 Logging APIs Proposal: Commons Logging +1 On Tue, 26 Oct 2004 01:14:40 -0400, Ted Husted wrote: 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 * http://java.sun.com/j2se/1.5.0/index.jsp Since Struts 1.x is in evolutionary mode, we might as well start the revolution based on the latest and greatest. We'd then be able to take advantage of annotations, generics, and all that. From the traffic on the list, I have the feeling many of us have JDK 5.0 itches. I'm getting one myself :) As Apache Beehive reasoned, by the time we are done, it will be widely deployed. If we both base our work on JDK 5.0, we might help that become a self-fulfilling prophesy :) 3.5 Service Provisioning APIs From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions. +1 On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: Date: 2004-10-24T21:56:45 Editor: CraigMcClanahan [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShale URL: http://wiki.apache.org/struts/StrutsShale Pointers to information about the Shale proposal New Page: This is a proposal for an overall architecture for Struts 2.0, based on dividing the controller tier into modular layers, and dramatically increasing the usability of the controller functionality. * [http://svn.apache.org/viewcvs.cgi/*checkout* /struts/trunk/contrib/struts-shale/README.html Proposal Details] (latest SVN version) * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] (periodically updated) -- -- - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I would be +1 for 1.5 as well -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:14 AM Subject: Struts Shale 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 * http://java.sun.com/j2se/1.5.0/index.jsp Since Struts 1.x is in evolutionary mode, we might as well start the revolution based on the latest and greatest. We'd then be able to take advantage of annotations, generics, and all that. From the traffic on the list, I have the feeling many of us have JDK 5.0 itches. I'm getting one myself :) As Apache Beehive reasoned, by the time we are done, it will be widely deployed. If we both base our work on JDK 5.0, we might help that become a self-fulfilling prophesy :) 3.5 Service Provisioning APIs From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions. +1 On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: Date: 2004-10-24T21:56:45 Editor: CraigMcClanahan [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShale URL: http://wiki.apache.org/struts/StrutsShale Pointers to information about the Shale proposal New Page: This is a proposal for an overall architecture for Struts 2.0, based on dividing the controller tier into modular layers, and dramatically increasing the usability of the controller functionality. * [http://svn.apache.org/viewcvs.cgi/*checkout* /struts/trunk/contrib/struts-shale/README.html Proposal Details] (latest SVN version) * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] (periodically updated) - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I'm +1 for 1.5 as well, but from memory I believe there were people who didn't want to be that bleeding edge. Niall - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 4:16 PM Subject: Re: Struts Shale I would be +1 for 1.5 as well James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:14 AM Subject: Struts Shale 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 * http://java.sun.com/j2se/1.5.0/index.jsp Since Struts 1.x is in evolutionary mode, we might as well start the revolution based on the latest and greatest. We'd then be able to take advantage of annotations, generics, and all that. From the traffic on the list, I have the feeling many of us have JDK 5.0 itches. I'm getting one myself :) As Apache Beehive reasoned, by the time we are done, it will be widely deployed. If we both base our work on JDK 5.0, we might help that become a self-fulfilling prophesy :) 3.5 Service Provisioning APIs From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions. +1 On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: Date: 2004-10-24T21:56:45 Editor: CraigMcClanahan [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsShale URL: http://wiki.apache.org/struts/StrutsShale Pointers to information about the Shale proposal New Page: This is a proposal for an overall architecture for Struts 2.0, based on dividing the controller tier into modular layers, and dramatically increasing the usability of the controller functionality. * [http://svn.apache.org/viewcvs.cgi/*checkout* /struts/trunk/contrib/struts-shale/README.html Proposal Details] (latest SVN version) * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] (periodically updated) - 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] - 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: Struts Shale
Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How do I send error messages back to the user interface? (With JSF, you call FacesContext.addMessage().) * How do I initiate page navigation? (With JSF, the string outcome returned by an action method is fed through the page navigation rules you've configured to choose the next page, or null return means stay on the same page). All of those sorts of decisions have predefined answers in JSF, and abstracting them would require building infrastructure (into Struts Core) to bridge that gap into any other view tier technology you want, and/or reinventing a lot of what JSF (the managed beans, page navigation, and so on) already has. That's not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. 2.5 Functionality Not Included In Struts 2.0 Core Would any view packages be bundled with the 2.x core, or would the core be the Application controller and interfaces for the Dialog and View controllers (and any implementation-independent utilities). My current view is that no view *components* would be included in the core -- although, if we accept the proposal to base the core on JSF for its infrastructure capabilities, we'd need to have a JSF implementation available (even if an alternative view technology was used for the actual presentation). The core would also include preregistration of JSF plugins like a custom ViewHandler that would actually implement the ViewHandler calling-in contracts (but that's invisible to people using it; JSF recognizes META-INF/faces-config.xml files inside a JAR at startup time to add stuff like this). It's clearly reasonable to distribute separate view tier packages, including things like useful components (the way MyFaces does) and/or extra goodies for things like validation. 2.5 Functionality Not Included In Struts 2.0 Core Since client-side validation is mentioned, are we leaving the door open for server-side validation? My current view is that UI validation (as opposed to business rules that might require database lookups, like authenticating a user in a login screen) should be defined in the view tier. Whether it's implemented client side or server side (or both) is an implementation detail. Here's some options (again presuming a choice of JSF): * Standard JSF per-component validators (server side only for the standard components, but smarter components could do client side as well) * Special form tag component that hooks into an externally defined set of rules that enforce the rules both client and server side (this is what struts-faces does to hook into Commons Validator) * Special JSF ActionListener plugin (the part of JSF that receives submit buttons and decides what view controller to load, and what action method to call) that would hook in to the validator framework (this would work with the standard form component too) In none of the cases would the view controller's action method be called if there were validation errors (exactly analogous to how we don't call an Action if errors existed). Perhaps as an abstract link in the request processing chain? The third option above is probably the most elegant, and would certainly lend itself to inserting an arbitrary request processing
Re: Struts Shale
At 5:32 PM +0100 10/26/04, Niall Pemberton wrote: I'm +1 for 1.5 as well, but from memory I believe there were people who didn't want to be that bleeding edge. Or those who use a lovely operating system whose own Tiger release is still several months away, with no plans for Java 5.0 support before then... I love Mac OS X, but really wish Apple could close the Java gap a bit. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: Struts Shale
Some people already moan that struts is too jsp orientated with the tags that are included I'm not trying to tip the discussion in any direction here, but I thought I would point out that JSF is supposed to be view agnostic. Render kits are being built for WML, Swing, etc. I think that it is safe to assume that JSF would move Struts AWAY from its jsp orientation. and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:35 PM Subject: Re: Struts Shale I'm +1 on JDK 1.4 (+0 on JDK 1.5). I also agree with Craig's sentiments on keeping things as simple as possible and not reinventing what JSF (and other frameworks) can do for you. The more I look at JSF, the more impressed I am with it. In many ways it seems to be a signifcant improvement upon Struts but without the restrictions on being backwards compatible. Not suprising since Craig was key in both of these efforts ... I definitely feel that JSF should fit seemlessly into the new Shale effort. Right now its a bit awkward integrating Struts and JSF. That's to be expected because Struts was not designed with JSF in mind. Going forward, however, I think we diminish the value of both Struts and JSF if we don't take JSF strongly into account. From reading Craig's proposal and comment here, it sounds like that is his goal. I just wanted to second that notion. sean On Tue, 26 Oct 2004 09:34:07 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How do I send error messages back to the user interface? (With JSF, you call FacesContext.addMessage().) * How do I initiate page navigation? (With JSF, the string outcome returned by an action method is fed through the page navigation rules you've configured to choose the next page, or null return means stay on the same page). All of those sorts of decisions have predefined answers in JSF, and abstracting them would require building infrastructure (into Struts Core) to bridge that gap into any other view tier technology you want, and/or reinventing a lot of what JSF (the managed beans, page navigation, and so on) already has. That's not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. 2.5 Functionality Not Included In Struts 2.0 Core Would any view packages be bundled with the 2.x core, or would the core be the Application controller and interfaces for the Dialog and View controllers (and any implementation-independent utilities). My current view is that no view *components* would be included in the core -- although, if we accept the proposal to base the core on JSF for its infrastructure capabilities, we'd need to have a JSF implementation available (even if an alternative view technology was used
Re: Struts Shale
At 7:02 PM +0100 10/26/04, Niall Pemberton wrote: I'm all for taking JSF faces strongly into account, but the proposal seems to be *JSF only* for the view tier - to the exclusion of all others. Since I haven't tried out JSF yet and therefore don't know enough about it that makes me uneasy. Seems to me at this point that its early days to commit to a JSF only strategy. Some people already moan that struts is too jsp orientated with the tags that are included and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. I don't think that's true. In order to disagree with this strategy, you need to be interested enough in some non JSF view tier to find it worthwhile to give Struts an adapter that works with JSF as well as non JSF view technologies. Although I'm a JSP user and interested in JSF, I'm also interested in trying to keep Struts more view-agnostic. I understand Craig's point about reinventing APIs that JSF already has (and his personal disinterest in doing that work) so I need to have a better handle on what all that would take before I agree or disagree with the strategy. I would definitely endorse designing to take full advantage of ideas gained from JSF, and as we move towards that, we should get a better idea of what it would take to abstract away from a JSF dependency -- then we can see who's willing to do it! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana
Re: Struts Shale
Niall Pemberton wrote: I'm all for taking JSF faces strongly into account, but the proposal seems to be *JSF only* for the view tier - to the exclusion of all others. Since I haven't tried out JSF yet and therefore don't know enough about it that makes me uneasy. Is this correct? I did get that there was an optional controller with this sort of emphasis, but I read the proposal as allowing custom controllers to do pretty much whatever one wanted. Am I off the beam? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I take your points but I probably didn't express this very well - I was thinking more that in the same way that jsp is a standard java technolody and has its supporters/detractors - the same will probably be true of JSF. The jsp detractors don't like the jsp orientation even when Struts isn't actually tied to it - if its a you have to use JSF to use Struts what reaction is that going to get? I guess that if the overwhelming majority of people want to use JSF, then its not really an issue - but at this point in time it isn't a given IMO. As I said I need try JSF out and this was only intended as an initial *musing*. Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 7:03 PM Subject: Re: Struts Shale Some people already moan that struts is too jsp orientated with the tags that are included I'm not trying to tip the discussion in any direction here, but I thought I would point out that JSF is supposed to be view agnostic. Render kits are being built for WML, Swing, etc. I think that it is safe to assume that JSF would move Struts AWAY from its jsp orientation. and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:35 PM Subject: Re: Struts Shale I'm +1 on JDK 1.4 (+0 on JDK 1.5). I also agree with Craig's sentiments on keeping things as simple as possible and not reinventing what JSF (and other frameworks) can do for you. The more I look at JSF, the more impressed I am with it. In many ways it seems to be a signifcant improvement upon Struts but without the restrictions on being backwards compatible. Not suprising since Craig was key in both of these efforts ... I definitely feel that JSF should fit seemlessly into the new Shale effort. Right now its a bit awkward integrating Struts and JSF. That's to be expected because Struts was not designed with JSF in mind. Going forward, however, I think we diminish the value of both Struts and JSF if we don't take JSF strongly into account. From reading Craig's proposal and comment here, it sounds like that is his goal. I just wanted to second that notion. sean On Tue, 26 Oct 2004 09:34:07 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How do I send error messages back to the user interface? (With JSF, you call FacesContext.addMessage().) * How do I initiate page navigation? (With JSF, the string outcome returned by an action method is fed through the page navigation rules you've configured to choose the next page, or null return means stay on the same page). All of those sorts of decisions have predefined answers in JSF, and abstracting them would require building infrastructure (into Struts
Re: Struts Shale
OK Craig didn't say it was JSF only - but that was my interpretation of the likely direction. He said The interface as currently defined is not dependent on JSF but then went on to say that JSF already solves a whole load of the view tier issues and re-inventing them outside JSF is ...not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. Niall - Original Message - From: Michael McGrady [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 7:21 PM Subject: Re: Struts Shale Niall Pemberton wrote: I'm all for taking JSF faces strongly into account, but the proposal seems to be *JSF only* for the view tier - to the exclusion of all others. Since I haven't tried out JSF yet and therefore don't know enough about it that makes me uneasy. Is this correct? I did get that there was an optional controller with this sort of emphasis, but I read the proposal as allowing custom controllers to do pretty much whatever one wanted. Am I off the beam? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
If Niall is right that JSF is a required aspect of the proposals, I would agree with him. This is not a negative toward JSF in any sense. The jury in my head is out on that one and is finding some nice things there. However, I do think that choices are excellent in any framework. And, so, I think that the ability to put in one's own controller, which I think is there, is important. Is Niall right on this? I had thought he was not. Michael McGrady Niall Pemberton wrote: I take your points but I probably didn't express this very well - I was thinking more that in the same way that jsp is a standard java technolody and has its supporters/detractors - the same will probably be true of JSF. The jsp detractors don't like the jsp orientation even when Struts isn't actually tied to it - if its a you have to use JSF to use Struts what reaction is that going to get? I guess that if the overwhelming majority of people want to use JSF, then its not really an issue - but at this point in time it isn't a given IMO. As I said I need try JSF out and this was only intended as an initial *musing*. Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 7:03 PM Subject: Re: Struts Shale Some people already moan that struts is too jsp orientated with the tags that are included I'm not trying to tip the discussion in any direction here, but I thought I would point out that JSF is supposed to be view agnostic. Render kits are being built for WML, Swing, etc. I think that it is safe to assume that JSF would move Struts AWAY from its jsp orientation. and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:35 PM Subject: Re: Struts Shale I'm +1 on JDK 1.4 (+0 on JDK 1.5). I also agree with Craig's sentiments on keeping things as simple as possible and not reinventing what JSF (and other frameworks) can do for you. The more I look at JSF, the more impressed I am with it. In many ways it seems to be a signifcant improvement upon Struts but without the restrictions on being backwards compatible. Not suprising since Craig was key in both of these efforts ... I definitely feel that JSF should fit seemlessly into the new Shale effort. Right now its a bit awkward integrating Struts and JSF. That's to be expected because Struts was not designed with JSF in mind. Going forward, however, I think we diminish the value of both Struts and JSF if we don't take JSF strongly into account. From reading Craig's proposal and comment here, it sounds like that is his goal. I just wanted to second that notion. sean On Tue, 26 Oct 2004 09:34:07 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How do I send error messages back to the user interface? (With JSF, you
Re: Struts Shale
Sorry, I had not received Niall's email when this was sent. Michael McGrady wrote: If Niall is right that JSF is a required aspect of the proposals, I would agree with him. This is not a negative toward JSF in any sense. The jury in my head is out on that one and is finding some nice things there. However, I do think that choices are excellent in any framework. And, so, I think that the ability to put in one's own controller, which I think is there, is important. Is Niall right on this? I had thought he was not. Michael McGrady Niall Pemberton wrote: I take your points but I probably didn't express this very well - I was thinking more that in the same way that jsp is a standard java technolody and has its supporters/detractors - the same will probably be true of JSF. The jsp detractors don't like the jsp orientation even when Struts isn't actually tied to it - if its a you have to use JSF to use Struts what reaction is that going to get? I guess that if the overwhelming majority of people want to use JSF, then its not really an issue - but at this point in time it isn't a given IMO. As I said I need try JSF out and this was only intended as an initial *musing*. Niall - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 7:03 PM Subject: Re: Struts Shale Some people already moan that struts is too jsp orientated with the tags that are included I'm not trying to tip the discussion in any direction here, but I thought I would point out that JSF is supposed to be view agnostic. Render kits are being built for WML, Swing, etc. I think that it is safe to assume that JSF would move Struts AWAY from its jsp orientation. and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:35 PM Subject: Re: Struts Shale I'm +1 on JDK 1.4 (+0 on JDK 1.5). I also agree with Craig's sentiments on keeping things as simple as possible and not reinventing what JSF (and other frameworks) can do for you. The more I look at JSF, the more impressed I am with it. In many ways it seems to be a signifcant improvement upon Struts but without the restrictions on being backwards compatible. Not suprising since Craig was key in both of these efforts ... I definitely feel that JSF should fit seemlessly into the new Shale effort. Right now its a bit awkward integrating Struts and JSF. That's to be expected because Struts was not designed with JSF in mind. Going forward, however, I think we diminish the value of both Struts and JSF if we don't take JSF strongly into account. From reading Craig's proposal and comment here, it sounds like that is his goal. I just wanted to second that notion. sean On Tue, 26 Oct 2004 09:34:07 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How
Re: Struts Shale
Niall Pemberton wrote: OK Craig didn't say it was JSF only - but that was my interpretation of the likely direction. He said The interface as currently defined is not dependent on JSF but then went on to say that JSF already solves a whole load of the view tier issues and re-inventing them outside JSF is ...not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. Niall My understanding is that the interfaces will be optimized to a JSF emphasis but amenable to and sensitive to any other options nuts like myself might want to code. Is that right, Craig? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Niall Pemberton wrote: OK Craig didn't say it was JSF only - but that was my interpretation of the likely direction. He said The interface as currently defined is not dependent on JSF but then went on to say that JSF already solves a whole load of the view tier issues and re-inventing them outside JSF is ...not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. Niall My understanding is that the interfaces will be optimized to a JSF emphasis but amenable to and sensitive to any other options nuts like myself might want to code. Is that right, Craig? Let's look at this from a variety of perspectives: * The proposed Struts Core doesn't contain or use any JSF components -- it presumes the use of the infrastructure stuff (managed beans, expressions, navigation mapping, as well as the basic request processing lifecycle) that is darned useful, and would have to be reinvented by any non-JSF-based implementation anyway. * JSF itself is bound to JSP substantially less than Struts is, even though a JSF implementation is required to support JSP. For example, if you like Tapestry's approach of a separate HTML file containing markup with id attributes that correspond to a component tree, that's a very straightforward thing to implement -- indeed, Hans Bergsten's book gets you about 80% of the way there. Or, if you want to output WML or SVG instead of HTML ... that's nothing the controller need concern itself with -- just pick the correct JSF renderers. * The same thing could be done for any other templating technology that has some way to establish the data bindings (Velocity macros, for example) and is accessible via RequestDispatcher.forward() or a programmatic interface to actually do the rendering. I'd be OK with having a subproject lying around that implemented one or more of these adapters for view tier technologies; I can provide design assistance but not much in the way of development help due to time constraints. * That being said, JSF goes far beyond just using templates, because it provides a sophisticated component model (so you can build things like tree controls and scrollable tables) and an event model optimized for component oriented development. Choosing a templating technology which forces you to give that up seems to me a sub-optimal choice. But it could be done, if we're willing to simulate the controller-level parts of JSF. * Even if the core controller part of Struts was JSF-agnostic (except for an implementation of the APIs based on it), you still can't write an application on top of this without committing to a choice in view tier technology. The more stuff like how validation errors are propogated that we have to abstract in order to be JSF-agnostic, the more complicated we make the architecture; and the more code we have to wrte and fix and document and test. * JSF is going to be part of J2EE 5.0 anyway, so rumors of its imminent demise are not credible :-). * Indeed, Apache is currently incubating an open source implementation (http://incubator.apache.org/projects/myfaces.html) that will, naturally enough, be Apache licensed and suitable for distribution (once it passes the compatibility tests). * Finally, there's a marketing viewpoint :-). The world has changed since Struts was first developed, and there's so many frameworks out there that people get laughed at on TheServerSide etc. for creating YAWAF (yet another web application framework). Without some distinguishing characteristic, what (besides the Struts name) would we bring to the table that all the other non-JSF-specific frameworks already do? My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Michael McGrady Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 19:40:59 +0100, Niall Pemberton wrote: OK Craig didn't say it was JSF only - but that was my interpretation of the likely direction. Something to consider is that we are not constrained to a single line of development. We could proceed with Struts Shale as a subproject [org.apache.struts.shale], and see how it goes. If there's a way to bridge the gap between Struts 1.x and Shale, I'm sure someone will rush in to make it so. Meanwhile, people who are happy with Struts 1.x can continue evolving the tried-and-true codebase. Shale does seems like a fine idea for a JSF framework, but it really doesn't have a Struts 2.x feel. In fact, calling it Struts 2.x might cause a lot of confusion, unless there is a very clear migration path. But, that doesn't mean we can't host Struts Shale alongside Struts 1.x. We might also ask if our friends at Apache MyFaces would be interested in helping with Apache Shale, or even hosting the development. If this is going to be a JSF gizmo, and we are short of JSF developers here, perhaps Shale should live where more JSF developers hang out. Of course, if MyFaces doesn't want to get into the framework business, we can host it here, and perhaps some MyFaces developers will join us here. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: * The proposed Struts Core doesn't contain or use any JSF components -- it presumes the use of the infrastructure stuff (managed beans, expressions, navigation mapping, as well as the basic request processing lifecycle) that is darned useful, and would have to be reinvented by any non-JSF-based implementation anyway. This makes complete sense to me. JSF seems to handle these things really well so why reinvent the wheel on this? JSF does seem to be picking up momentum as a standard. It will take a while for sure, but if Craig is correct about it being part of J2EE 5.0, this will only hasten its adoption. At some point it will not make sense to continue evolving Struts in its current form. Bug fixes and minor tweaks are one thing, but we don't want to be working at cross purposes. If JSF can handle x,y, and z better then lets focus on what it doesn't handle very well. * Even if the core controller part of Struts was JSF-agnostic (except for an implementation of the APIs based on it), you still can't write an application on top of this without committing to a choice in view tier technology. The more stuff like how validation errors are propogated that we have to abstract in order to be JSF-agnostic, the more complicated we make the architecture; and the more code we have to wrte and fix and document and test. I agree with this statement as well. * Finally, there's a marketing viewpoint :-). The world has changed since Struts was first developed, and there's so many frameworks out there that people get laughed at on TheServerSide etc. for creating YAWAF (yet another web application framework). Without some distinguishing characteristic, what (besides the Struts name) would we bring to the table that all the other non-JSF-specific frameworks already do? I think this is a very important issue. If JSF does indeed catch on, then the very first thing a perspective user will want to know about Struts Shale is, How does this work with JSF? (Same as when JSF came along and we all asked ourselves, How does this fit in with Struts?) Let me summarize what I think Craig is suggesting. He and others can correct me if I'm wrong: 1.) Forget about backwards compatability with Struts 1.x 2.) Focus exclusively on value added to JSF (even if the user ultimately doesn't want to use JSF). This includes things like dialogs and would focus primarily on the controller 3.) Design with an eye towards using it with JSF but with little (or no) dependencies on it. We could continue to develop Struts 1.x versions for the forseeable future, but the real innovations would take place in Struts Shale. Thus users who migrate from Struts to JSF, and users who never used Struts and are starting with JSF, can use the new Struts Shale for the extra goodies. Users who want no part in JSF and like the old Struts framework can keep on with Struts 1.x (with the option to integrate with JSF using struts-faces.) Craig sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Struts (the controller) is pretty view agnostic as it sits now (unless there's been some change of which I am unaware). There are even non-http methods so that it can be used outside of a web application. I believe some folks have actually even done this. Struts does provide a lot to facilitate rendering a JSP view, but that's just because that's what's main-stream. There are kits to have Struts render to other views. I am a little nervous about using a JDK 1.5 base. I'd like to use this once there's a GA release, and I - being realistic and pragmatic - am not certain the company I work for will be running things on such a platform. I'm 250% for JDK 1.4 and Servlet spec 2.4 / JSP 2.0. That gives us a myriad of tools to use we haven't had at our disposal before now and also sets what I believe is realistically a possible common platform that folks will have available to use this when we do hit GA. If someone can convince me otherwise, I'd be happy to get behind the 1.5/5.0/?.?? band-wagon and hop on. Maybe I'll hit-up our farm-management guys and see what their expectations are for the next year. 2 cents, 4 cents, 6 cents ... a dollar! er ... maybe not :-) Eddie - Original Message - From: Michael Rasmussen [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:03 PM Subject: Re: Struts Shale Some people already moan that struts is too jsp orientated with the tags that are included I'm not trying to tip the discussion in any direction here, but I thought I would point out that JSF is supposed to be view agnostic. Render kits are being built for WML, Swing, etc. I think that it is safe to assume that JSF would move Struts AWAY from its jsp orientation. and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0444-0, 10/26/2004 Tested on: 10/26/2004 6:00:09 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
JSF is view agnostic isn't it? Plus, it's going to into the 5.0 spec, so
... with Struts having such a strong history of making use of industry
standards and best-practice approaches, doesn't it seem logical any
revolutionary new release would utilize JSF?
I've not looked at JSF enough to know what it can('t) do for me, but what
little I do know gives me warm fuzzies. I think it'd be serious overkill
for a simple web app though.
Perhaps what we ought to do is continue to let the 1.x and 2.x code-bases
evolve independent of one another. I know Martin (I believe it was Martin)
voiced some sentiment against this, but I think a Struts 1.x framework could
have a home in developers' toolboxes for some time yet.
Eddie
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 1:04 PM
Subject: Re: Struts Shale
At 7:02 PM +0100 10/26/04, Niall Pemberton wrote:
I'm all for taking JSF faces strongly into account, but the proposal seems
to be *JSF only* for the view tier - to the exclusion of all others. Since
I
haven't tried out JSF yet and therefore don't know enough about it that
makes me uneasy.
Seems to me at this point that its early days to commit to a JSF only
strategy. Some people already moan that struts is too jsp orientated with
the tags that are included and I'm wondering what proportion of the
exisiting Struts user base were going to loose/screw going that route?
I guess in order to agree/disagree with this stratgey I need to go and
actullay try JSF out.
I don't think that's true. In order to disagree with this strategy,
you need to be interested enough in some non JSF view tier to find it
worthwhile to give Struts an adapter that works with JSF as well as
non JSF view technologies.
Although I'm a JSP user and interested in JSF, I'm also interested in
trying to keep Struts more view-agnostic. I understand Craig's point
about reinventing APIs that JSF already has (and his personal
disinterest in doing that work) so I need to have a better handle on
what all that would take before I agree or disagree with the strategy.
I would definitely endorse designing to take full advantage of ideas
gained from JSF, and as we move towards that, we should get a better
idea of what it would take to abstract away from a JSF dependency --
then we can see who's willing to do it!
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place.
- Carlos Santana
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0444-0, 10/26/2004
Tested on: 10/26/2004 6:04:38 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
