I couldn't sleep, so I've been spending the night looking at a few
things, amoung them Shale. I was wondering what a good starting place
would be to get up to speed quickly, since I haven't really looked at
JSF or Shale before now.
I thought I'd start by checking out the Use Cases sample app, which I'm
exploring now, but I'm finding (using the 20051117 nightly) that it's
not too stable -- about half the links on the front page aren't working,
and I keep getting into a borked-session situation that results in 500
errors until I clear the session cookie (I think mostly if I hit the
browser 'back' button).
So, I was wondering if there was a better place to start? Any pointers
welcome!
L.
To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Wendy Smoak wrote:
11/18/05, Laurie Harper <laurie (AT) holoweb (DOT) netwrote:

>>I couldn't sleep, so I've been spending the night looking at a few
>>things, amoung them Shale. I was wondering what a good starting place
>>would be to get up to speed quickly, since I haven't really looked at
>>JSF or Shale before now.

There's a four part series on IBM DeveloperWorks that should get you
started with JSF. Then buy David's book. :)

I wont be buying any books unless I'm already hooked by the time I 'wake
up' and have to go back to work ;-) Thanks for the pointer, though, that
looks like good reading.

For Shale, there's just the website, and the usual check the list
archives. Craig and Gary have written some really good explanations
in response to user questions. My new favorite place to search is
Nabble-- you can search both lists at once:

I had a feeling ;-)

>>I thought I'd start by checking out the Use Cases sample app, which I'm
>>exploring now, but I'm finding (using the 20051117 nightly) that it's
>>not too stable -- about half the links on the front page aren't working,
>>and I keep getting into a borked-session situation that results in 500
>>errors until I clear the session cookie (I think mostly if I hit the
>>browser 'back' button).

Depending on where you were using the back button, it might be this:

Yup, looks like it.

The Maven-build use-cases app was somewhat broken until Gary committed
r345441 last night. Try the 20051118 version in case the Ant build
was similarly affected or just build it yourself. (Ant build files
are in the usual place, look in shale/build for the Maven ones, and
check the README file.)

Typical, I was only a day (probably a few hours!) too soon. I have the
sources locally, so I'll just rebuild.

Thanks to James, we now have Shale Mailreader. :) If you're familiar
with the original version, that might be a better place to start than
the use cases.

Good point, forgot that existed.

L.

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Nov 18, 2005, at 6:04 AM, Laurie Harper wrote:

I couldn't sleep, so I've been spending the night looking at a few
things, amoung them Shale. I was wondering what a good starting
place would be to get up to speed quickly, since I haven't really
looked at JSF or Shale before now.

I personally found it overwhelming to figure out Shale with no
understanding of JSF. So I started with vanilla JSF using MyFaces
and using the JSF Tutorial at coreservlets.com (http://
). After spending a very limited
amount of time with plain ol' JSF I'm starting to see benefit in
Shale, but I haven't really gotten back around to fooling with it more.

Greg

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

11/18/05, Greg Reddin <greddin (AT) apache (DOT) orgwrote:
--
Nov 18, 2005, at 6:04 AM, Laurie Harper wrote:

I couldn't sleep, so I've been spending the night looking at a few
things, amoung them Shale. I was wondering what a good starting
place would be to get up to speed quickly, since I haven't really
looked at JSF or Shale before now.

I personally found it overwhelming to figure out Shale with no
understanding of JSF. So I started with vanilla JSF using MyFaces
and using the JSF Tutorial at coreservlets.com <http://coreservlets.com>(http://
)<)>.
After spending a very limited
amount of time with plain ol' JSF I'm starting to see benefit in
Shale, but I haven't really gotten back around to fooling with it more.

That approach (start with pure JSF, then come back) is probably the wisest.
Shale's assumption that JSF exists is so fundamental that it dispenses not
only duplicating functionality, but duplicating documentation :-) That's
something that will likely need to be improved in the long run.

And, as to dialogs, yes in the current implementation, back buttons are
death (as well as multiple simultaneous dialogs). That's very high on my
priority list for *after* the whole darn thing is stable enough for a
1.0.0alpha-quality milestone.

Greg

Craig

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

Craig McClanahan wrote:
11/18/05, Greg Reddin <greddin (AT) apache (DOT) orgwrote:
>Nov 18, 2005, at 6:04 AM, Laurie Harper wrote:
I couldn't sleep, so I've been spending the night looking at a few
things, amoung them Shale. I was wondering what a good starting
place would be to get up to speed quickly, since I haven't really
looked at JSF or Shale before now.
>>
>>I personally found it overwhelming to figure out Shale with no
>>understanding of JSF. So I started with vanilla JSF using MyFaces
>>and using the JSF Tutorial at coreservlets.com <http://coreservlets.com>(http://
>>)<)>.
>>After spending a very limited
>>amount of time with plain ol' JSF I'm starting to see benefit in
>>Shale, but I haven't really gotten back around to fooling with it more.

That approach (start with pure JSF, then come back) is probably the wisest.
Shale's assumption that JSF exists is so fundamental that it dispenses not
only duplicating functionality, but duplicating documentation :-) That's
something that will likely need to be improved in the long run.

Yeah, after trying to pull Shale into an existing Struts app, then
trying to get it going from scratch, then trying to get Creator going I
came to the same conclusion and downloaded MyFaces. 20 minutes later and
I had a working application :-)

And, as to dialogs, yes in the current implementation, back buttons are
death (as well as multiple simultaneous dialogs). That's very high on my
priority list for *after* the whole darn thing is stable enough for a
1.0.0alpha-quality milestone.

Ugh, yeah, that'd be a total show stopper for me as far as adopting
Shale right now Not for giving it a good poke and finding out what
it's all about though.

L.

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

11/18/05, Laurie Harper <laurie (AT) holoweb (DOT) netwrote:
Craig McClanahan wrote:
<snip/>
And, as to dialogs, yes in the current implementation, back buttons are
death (as well as multiple simultaneous dialogs). That's very high on my
priority list for *after* the whole darn thing is stable enough for a
1.0.0alpha-quality milestone.

Ugh, yeah, that'd be a total show stopper for me as far as adopting
Shale right now Not for giving it a good poke and finding out what
it's all about though.

<snap/>

I found a solution for my needs for browser navigation buttons. I
intend to backport to the default Shale dialogs and propose a patch,
but given the serious dearth of time in the upcoming travel/holiday
season, it might not be too soon.

In any case, the background URLs are here [1],[2].

I see room for improvement in the following places in Shale dialogs:
1) Two or more dialogs in one session
2) Two or more of the same dialog in one session
3) Delegating inconsequential outcomes
4) Client-server dialog synchronization

IM, each is a separate issue and requires separate thought. I've
started bottom up, one down, three to go.
-Rahul

[1]
[2] http://people.apache.org/~rahul/shale/align-dialog/

L.

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Craig McClanahan wrote:
And, as to dialogs, yes in the current implementation, back buttons are
death (as well as multiple simultaneous dialogs). That's very high on my
priority list for *after* the whole darn thing is stable enough for a
1.0.0alpha-quality milestone.

The more I play with Faces, the more I suspect that the back button is
going to be pretty dangerous for and Faces app I've figured out that
telling the JSF implementation to persist component state on the client
rather than the server helps a lot, but it still seems *very* easy to
get into an inconsistent state if the user jumps back in their browser
history (via the back button or otherwise)

I'm guessing there are patterns and best practices that can be used in
writing backing beans, action handler methods and such that can help
mitigate this but, realistically, how difficult is it to write faces
apps that are robust in the face of the back button/browser
history/bookmarks? I know the toy app I wrote on Friday isn't, and I
don't yet know enough to figure out how to make it so.

Now the really hard question: is it possible to achieve the same goals
*without* storing state on the client side?

And finally: does (or could) Shale in any way help with any of this?

I'm definately thinking about migrating to JSF if I can figure out how
to solve a few concerns like these, so it looks like that one sleepless
night Thursday/Friday may be going to cost me many more to come ;-)

L.

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

11/20/05, Laurie Harper <laurie (AT) holoweb (DOT) netwrote:

Craig McClanahan wrote:
And, as to dialogs, yes in the current implementation, back buttons
are
death (as well as multiple simultaneous dialogs). That's very high on my
priority list for *after* the whole darn thing is stable enough for a
1.0.0alpha-quality milestone.

The more I play with Faces, the more I suspect that the back button is
going to be pretty dangerous for and Faces app I've figured out that
telling the JSF implementation to persist component state on the client
rather than the server helps a lot, but it still seems *very* easy to
get into an inconsistent state if the user jumps back in their browser
history (via the back button or otherwise)

I'm guessing there are patterns and best practices that can be used in
writing backing beans, action handler methods and such that can help
mitigate this but, realistically, how difficult is it to write faces
apps that are robust in the face of the back button/browser
history/bookmarks? I know the toy app I wrote on Friday isn't, and I
don't yet know enough to figure out how to make it so.

Now the really hard question: is it possible to achieve the same goals
*without* storing state on the client side?

And finally: does (or could) Shale in any way help with any of this?

At the end of the day, back buttons need to be addressed at the JSF level
for use cases when you're using it directly (as well as Shale needing to
address it for the specific case of dialogs). I know there's been some work
done in the JSF RI for 1.2 that targets this problem (and some of it might
have been backported to the 1.1 RI available at java.net <http://java.net>;
haven't had time to check yet).

For Shale, I see that Rahul has submitted a proposed patch for dialogs and
the back button, although my inclination is to defer all those fixes to
1.0.1 so we can actually get a milestone out the door -- with appropriate
caveats.

I'm definately thinking about migrating to JSF if I can figure out how
to solve a few concerns like these, so it looks like that one sleepless
night Thursday/Friday may be going to cost me many more to come ;-)

L.

Craig