Re: [Shale] getting my first dialog to work with Shale/MyFaces

[Rahul Akolkar]

On 1/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 1/7/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> > * A self transition for a view state should be possible (its
> > definitely legit in state chart theory, Shale dialogs being state
> > charts for a specific purpose).
>
>
> Self-transitions for a view state are definitely legal, but there's an
> interesting semantic twist here.  Since we are in a view state, the
> transition is based on the logical outcome returned by the action method
> that is invoked for the submit button that actually submits the form (phew,
> say that sentence three times real fast :-).  If the action method returns
> an outcome that happens to map to the same view identifier, a *new*
> component tree is still created, so you lose any state information you've
> stored in the current component tree.  If the action method returns null, on
> the other hand, there is a short circuit to the normal transition mechanism
> that causes the current view to be redisplayed, *without* being recreated.
>
> This was done deliberately, so that action methods within a dialog work
> exactly the way they do outside a dialog.  From a state chart perspective,
> you can assume there is an additional unspecified transition that says "if
> the logical outcome is null, redisplay the current component tree without
> recreating it."  This can be an important consideration when you are
> designing the UI of your application ... even if the *user* doesn't know or
> care whether a new view was created or not in this scenario, it can
> dramatically simplify your dialog configuration, and your application logic,
> to know that this is a scenario you can rely on.
>


That makes sense. A "stay" (null) transition should retain state, a
"self" transition (amounts to calling onexit and onentry -- which gets
us in initial -- for that state) should not.

Now in terms of DialogNavigationHandler#transition(...) a null outcome
and a stay transition seems to produce the identical State as a return
value and hence identical results from a dialog progression
perspective. A quick test by making the "next" transition on page 2 of
the edit profile dialog (from the shale usecases war) point to the
same state seemed to retain the values in the s. Is my
quick test missing something?

-Rahul

> Craig
>
>

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

Re: Advice for Struts expert wanting to try Shale?

[Craig McClanahan]

Just a couple of comments intermixed below.

On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
>
> Ok can we all ignore the troll and go back to the original subject...
>
> Like Craig pointed out Rick, I think you should play around with JSF
> first and then Shale.
> The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> think one of the previous poster posted the link.
>
> Shale is decomposed in modules so it not so hard to get a grab on the
> functionalities, one type at a time. Actually, it's not very complex
> except maybe the Clay plugin wich does require some time to understand
> but using it or Facelets instead of JSP is worth the troubles in my
> opinion.
>
> Anyway, I have been playing with JSF for sometimes now and here's the
> various differences against Struts I've found :
>
> - ActionForm and Action (more Dispatch Action in fact) are replaced by
> backing beans.
> No more copy between ActionForm and Domain objets or data transfer
> objects are necessary.
>
> -The event model is fine-grained instead of coarse-grained. In struts,
> you don't have a true event model and the only event is receive a
> request and the *listeners* Action, are application wide.
>
> In JSF, the basic event listener are registered on a single component
> instead of the complete application. You have two basic different
> events (ActionEvent and ValueChangeEvent) and the event listeners all
> receive an event object representing the event context.


While these are the only two events defined in the standard, it is perfectly
feasible for JSF components to define their own events, and their own event
handlers, using the same basic infrastructure.

Plus, in JSF
> you can register more then one listeners on a component so no need for
> Action chaining and the troubles coming along with it. Note that the
> action events listeners are not responsible to choose the next view
> like the actions are in Struts. It's quite a change but you get used
> to it very fast in the end and this way your backing beans (most of
> the time, they are the action listeners) are easier to reuse. Overall,
> you can understand this quite fast if you are use to program Swing
> applications.


I actually wish there wasn't be so much difference here :-(.  In the
original vision of Struts, the idea of an ActionForward was very much to
describe an *outcome* ("this is what happened"), not a *destination* ("this
is where to go next").  Unfortunately, most Struts developers don't use
forwards that way -- and you can make exactly the same "mistake" :-) when
using logical outcomes in JSF.

- The binding mechanism is way more powerful then Struts one and I
> think this is where JSF really shine. In struts, you could only match
> form beans properties to forms html tags and it was complex to bind
> complex forms. In JSF, you can use EL value bindings or method
> bindings expressions. It is really great in my mind and very simple at
> the same time, thank to IoC and managed beans.


The synergy of the managed beans facility is pretty nice ... especially when
you realize you can use bindings on *any* property of *any* component, not
just on the "value" property of an input component.

- Finally, JSF has a component model and so reusing is very easy. The
> components hide most of the complexity to the developper (ugly
> javascript for exemple). Learning to developp components is what take
> time to learn, but you can get started quite fast if you just want to
> use it first. At least, there are a lot of exemples available.
>
> - One last thing, since the data and method bindings are specified in
> the "jsp/html/whatever technologie you use for view" page and the
> navigation is specified globally in the configuration file (not per
> action like in Struts), it is quite easy to follow the application
> flow. It was something that was annoying me sometimes with Struts, lot
> of places to look to find where the executed code is located.


In both environments, the navigation rules are defined globally.  The
difference in granularity is how a navigation rule is selected:

* In Struts, it's based solely on the outcome returned by a particular
action
  (which can be defined either globally or locally).

* In JSF, it's based (at least for the standard navigation handler; you can
replace
  this if you want something different) on three criteria:
  - What page am I currently on?
  - Which action method was executed?
  - What logical outcome was returned by the executed method?

In the JSF case, there are wildcarding capabilities for navigation that also
let you be pretty concise in what you actually have to specify for common
cases.

I hope it's help and since I am far from considering me a JSF expert,
> anyone can feel free to correct me. And please be tolerant about my
> english since I am not a native speaker and it's quite a long post :)


You're doing great ...  once you get me past a restaurant menu, my grasp of
French is *really* limited :-).

On

Re: [Shale] getting my first dialog to work with Shale/MyFaces

[Craig McClanahan]

On 1/7/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> [snip]
> * A self transition for a view state should be possible (its
> definitely legit in state chart theory, Shale dialogs being state
> charts for a specific purpose).


Self-transitions for a view state are definitely legal, but there's an
interesting semantic twist here.  Since we are in a view state, the
transition is based on the logical outcome returned by the action method
that is invoked for the submit button that actually submits the form (phew,
say that sentence three times real fast :-).  If the action method returns
an outcome that happens to map to the same view identifier, a *new*
component tree is still created, so you lose any state information you've
stored in the current component tree.  If the action method returns null, on
the other hand, there is a short circuit to the normal transition mechanism
that causes the current view to be redisplayed, *without* being recreated.

This was done deliberately, so that action methods within a dialog work
exactly the way they do outside a dialog.  From a state chart perspective,
you can assume there is an additional unspecified transition that says "if
the logical outcome is null, redisplay the current component tree without
recreating it."  This can be an important consideration when you are
designing the UI of your application ... even if the *user* doesn't know or
care whether a new view was created or not in this scenario, it can
dramatically simplify your dialog configuration, and your application logic,
to know that this is a scenario you can rely on.

Craig

Re: Advice for Struts expert wanting to try Shale?

[Alexandre Poitras]

Ok can we all ignore the troll and go back to the original subject...

Like Craig pointed out Rick, I think you should play around with JSF
first and then Shale.
The IBM serie "Cleared FUD about JSF" is a good introduction to. I
think one of the previous poster posted the link.

Shale is decomposed in modules so it not so hard to get a grab on the
functionalities, one type at a time. Actually, it's not very complex
except maybe the Clay plugin wich does require some time to understand
but using it or Facelets instead of JSP is worth the troubles in my
opinion.

Anyway, I have been playing with JSF for sometimes now and here's the
various differences against Struts I've found :

- ActionForm and Action (more Dispatch Action in fact) are replaced by
backing beans.
No more copy between ActionForm and Domain objets or data transfer
objects are necessary.

-The event model is fine-grained instead of coarse-grained. In struts,
you don't have a true event model and the only event is receive a
request and the *listeners* Action, are application wide.

In JSF, the basic event listener are registered on a single component
instead of the complete application. You have two basic different
events (ActionEvent and ValueChangeEvent) and the event listeners all
receive an event object representing the event context. Plus, in JSF
you can register more then one listeners on a component so no need for
Action chaining and the troubles coming along with it. Note that the
action events listeners are not responsible to choose the next view
like the actions are in Struts. It's quite a change but you get used
to it very fast in the end and this way your backing beans (most of
the time, they are the action listeners) are easier to reuse. Overall,
you can understand this quite fast if you are use to program Swing
applications.

- The binding mechanism is way more powerful then Struts one and I
think this is where JSF really shine. In struts, you could only match
form beans properties to forms html tags and it was complex to bind
complex forms. In JSF, you can use EL value bindings or method
bindings expressions. It is really great in my mind and very simple at
the same time, thank to IoC and managed beans.

- Finally, JSF has a component model and so reusing is very easy. The
components hide most of the complexity to the developper (ugly
javascript for exemple). Learning to developp components is what take
time to learn, but you can get started quite fast if you just want to
use it first. At least, there are a lot of exemples available.

- One last thing, since the data and method bindings are specified in
the "jsp/html/whatever technologie you use for view" page and the
navigation is specified globally in the configuration file (not per
action like in Struts), it is quite easy to follow the application
flow. It was something that was annoying me sometimes with Struts, lot
of places to look to find where the executed code is located.

I hope it's help and since I am far from considering me a JSF expert,
anyone can feel free to correct me. And please be tolerant about my
english since I am not a native speaker and it's quite a long post :)

On a side note for people having experience developping custom
components, what annoys me so far in JSF is the model package, in fact
the SelectItem class. There are no model objets for action components
(like you need for a menu or navigation panel) and no universal
components (UISelectItem and UISelectItems) for specifying the model.
You need one for each component and it is quite a pain in the a.. to
code those again and again. Anyway, it always possible to develop your
own model hierarchy and use an adaptor to make SelectItem compatible
with it. As anyone had the same problem so far? If it is the case,
maybe a solution could be part of the future commons-jsf package that
have been discussed in the past. I am working on something around this
problem so I could probably submit it once I'm done.

On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> LOL  I gave him the very same answer that you did, including the same
> citations.  The difference is that I did not gloss over the confusion you
> have systematically engendered by not just owning up to the differences from
> day one.  You don't have to love something to explain it.  Otherwise, who
> would have known about the ugly duckling?
>
> On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > If you are familiar with Core J2EE Patterns terminology, you'll find it
> > easiest to understand JSF and Shale in terms of the View Helper[1]
> > pattern,
> > where the helper items are the JSF component tags and your backing beans,
> > and the Dispatcher View[2] pattern, which combines the Front Controller[3]
> > and View Helper[1] patterns together.  In the Dispatcher View sequence
> > diagram (Figure 7.25) the roles and responsibilities match up like this:
> > Don't expect much help from someone who doesn't seem to care much for
> > eith

Re: [Shale] getting my first dialog to work with Shale/MyFaces

[Rahul Akolkar]

On 1/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Rahul Akolkar <[EMAIL PROTECTED]> wrote on 01/06/2006 05:07:21 PM:
>
> > On 1/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 
> > My "Search" still throws
> > > a nasty error, but I guess I shall struggle with that awhile before
> > > I give up and ask you again..(:(
> > >
> > 
> >
> > Possibly rethink the corresponding outbound transition from the
> > SearchHome view state (separate the search and results views).
>
> Thank you Rahul. Actually the specs are that my results appear just below
> my search form and I had already coded things so everything was in
> /search.jsp (I used rendered attributes to render results if present).
> However I guess what Shale requires is for the ids (names) to be different
> (and never mind what those names map to).


Not really. I understand your "specs" now, whats the "nasty error" you
refer to, does that hold any clues?


>
> So that's what i did:
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
> This worked for my *first* search: my searchBean.find() returns "
> ContactListSuccess" and everything is hunky dory. Sweet. *However*, since
> my search form is visble above my results, I got a Faces error when I
> searched again! And the error made sense too (;) since I was in the
> "ContactListSuccess" state (after the first successful search) and I was
> now transitioning to "ContactSearchSuccess" again due to the second
> search, which is not a legal outcome according to the dialog. So I moved
> the  up
> so it was a common transition (instead of adding it twice) and then I no
> longer got the error.
>


A couple of things that I think are relevant here:

 * A self transition for a view state should be possible (its
definitely legit in state chart theory, Shale dialogs being state
charts for a specific purpose).

 * I tend to use action states since I can visualize the processing
bits as states in the dialog config (and searching definitely
qualifies), and the corresponding multiple logical outcomes (error, no
results, few results, many results) appear as transitions in the
action state. But, I understand this is subjective.


> Furthermore, my menu bar, which is always visible and which has a link to
> dialog:Search Contacts also is always clickable. Thus I also need a common
> transition for outcome "Search Contacts". So my dialog now looks like
> this:
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
> I do have a few more transitions which I have omitted (which are not
> common), but it really seems to me that by making so many of the
> transitions "common", I am not utilizing what Shale can give me via
> dialogs. Is this correct? Or is this what i have to live with since my
> specs dictate I show the search form above my results and I always have
> the menu bar visible? I get the feeling I may be missing something
> important..
>


There is nothing wrong with "common" transitions -- Shale calls these
global transitions -- pending they're truly common. Looking at what
you have listed:

 * Transitions such as the first one (cancel) are useful when
specified as global transitions, especially in wizard style dialogs,
otherwise you'd be authoring them redundantly.

 * The second one is a candidate for localizing (will be a side-effect
of having one view state).

 * The third one I believe is refering to the "always clickable" menu
bar link to initiate the search dialog, and that is going to be
suspect since Shale dialogs, as of today, work best when you run a
dialog to completion before beginning another (where completion is
defined as reaching an end state, that says nothing about any *task*
being completed). Ofcourse, if you're using dialogs, it'd be good be
aware of the known issues 35066 [1], 37120 [2] and 37571 [3], if
you're not already.

And finally, use the latest nightlies if you can, just saw r366984 [4]
whiz by, that added better error messages for dialogs.

-Rahul

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=35066
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120
[3] http://issues.apache.org/bugzilla/show_bug.cgi?id=37571
[4] http://svn.apache.org/viewcvs?rev=366984&view=rev


> >
> > -Rahul
>
> Once again thank you for your time and patience!
> Geeta
>
>

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

Re: How to merely retrieve data? -> Newbie looking for best practices

[Eric Rank]

Ahhh yes. Actually, I did check out the DTD a couple of days ago. I
remember it saying how you can only put in one "forward" "include" or
"type". I just didn't connect how I would set a "type" and then
specify a forward as the child node. Now it works just fine.

I knew it was probably something simple. I appreciate your help!

Thanks,

Eric


On 1/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On 1/7/06, Eric Rank <[EMAIL PROTECTED]> wrote:
>
> > My goal is to retrieve data, which a jsp will spill out. I'm trying to
> > do it by writing a simple Action subclass to get the data and send it
> > along. The way I'm doing it isn't working.
> >
> > My action mapping looks like this:
> >
> >  > path="/records"
> > type="app.actions.RecordsAction"
> > forward="/pages/records.jsp" />
>
> Welcome!
>
> There's quite a bit of information in the DTD itself:
>http://struts.apache.org/dtds/struts-config/1_2/
>
> Click on 'action' and then scroll up a bit to read the comments.  For
> "forward", it says:
>Exactly one of "forward", "include", or "type" must be specified.
>
> Instead of the forward attribute, try using a nested (or global)
>
> element.
>
> And yes, setting attributes in the request or session and retrieving
> them in the JSP is a reasonable thing to do.   Take a look at JSTL if
> you aren't already using it.
>

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

Re: How to merely retrieve data? -> Newbie looking for best practices

[Wendy Smoak]

On 1/7/06, Eric Rank <[EMAIL PROTECTED]> wrote:

> My goal is to retrieve data, which a jsp will spill out. I'm trying to
> do it by writing a simple Action subclass to get the data and send it
> along. The way I'm doing it isn't working.
>
> My action mapping looks like this:
>
>  path="/records"
> type="app.actions.RecordsAction"
> forward="/pages/records.jsp" />

Welcome!

There's quite a bit of information in the DTD itself:
   http://struts.apache.org/dtds/struts-config/1_2/

Click on 'action' and then scroll up a bit to read the comments.  For
"forward", it says:
   Exactly one of "forward", "include", or "type" must be specified.

Instead of the forward attribute, try using a nested (or global)
   
element.

And yes, setting attributes in the request or session and retrieving
them in the JSP is a reasonable thing to do.   Take a look at JSTL if
you aren't already using it.

--
Wendy

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

How to merely retrieve data? -> Newbie looking for best practices

[Eric Rank]

Greetings!

First, I'm new to Struts, and pretty green in my Java skills, but I'm
excited about learning both!

My goal is to retrieve data, which a jsp will spill out. I'm trying to
do it by writing a simple Action subclass to get the data and send it
along. The way I'm doing it isn't working.

My action mapping looks like this:




My app.actions.RecordsAction looks approximately like this:

public class RecordsAction extends Action {

public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)throws IOException, 
ServletException{

RecordList rl = new RecordList(); //Object used to get 
records
List l = rl.getRecords();
request.setAttribute("records",l);
return  mapping.findForward("could-be-anything");
}
}

The result is that I get forwarded to /pages/records.jsp without the
"execute" method ever being called in RecordsAction, and as such, I
get a null pointer when I try to do anything with the
request.getAttribute("records") in the jsp. However, this seems to
make perfect sense because I specified this to merely forward. So, how
do I get the data?

If I want to simply return dynamically generated content, without an
ActionForm, what's the best practice for retrieving it?

1.What should the Action subclass look like?
2. What would the  in struts-config.xml look like?
3. Is it common to use request.setAttribute("value") to send data to
the View? and if not, what's the correct way to send data to the View
layer? (I think this is the pivotal question)

I've been going through Struts in Action, which I find good as a
technical reference, but not so good when it comes to figuring out how
to achieve a simple goal, like this. In my quick research in the book
and online, everything I've found seems to be tied to ActionForms. But
I don't have an ActionForm. Alas!

I realize that I am probably missing something fundamentally basic and
that y'all might tell me to go RTFM. And that's cool, just point me to
it. Most of the stuff I've seen is very focussed on dealing with data
AND forms, but not data by itself. I'd be happy to find some
recommended documentation.

Thanks for your collective help in getting me on track!

Eric Rank

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

Re: Advice for Struts expert wanting to try Shale?

[Dakota Jack]

LOL  I gave him the very same answer that you did, including the same
citations.  The difference is that I did not gloss over the confusion you
have systematically engendered by not just owning up to the differences from
day one.  You don't have to love something to explain it.  Otherwise, who
would have known about the ugly duckling?

On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
>
> If you are familiar with Core J2EE Patterns terminology, you'll find it
> easiest to understand JSF and Shale in terms of the View Helper[1]
> pattern,
> where the helper items are the JSF component tags and your backing beans,
> and the Dispatcher View[2] pattern, which combines the Front Controller[3]
> and View Helper[1] patterns together.  In the Dispatcher View sequence
> diagram (Figure 7.25) the roles and responsibilities match up like this:
> Don't expect much help from someone who doesn't seem to care much for
> either
> JSF or Shale :-).
>
> Mark
>
>
> Craig
>
> [1]
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
> [2]
>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
> [3]
>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Advice for Struts expert wanting to try Shale?

[Craig McClanahan]

On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

> In a JSF application, there's actually two ways to implement classic Front
> Controller type functionality, such as "send the user to the logon page if
> they are not currently logged on":
>

Concrete examples will help make this clearer, so here are the pure-servlet
and pure-JSF ways to accomplish this:

* With a servlet Filter that gets invoked in front of the JSF controller
> (Shale has support for this).  When
>   Struts 1.0 was created, there was no such thing, so we had to provide
> this capability inside ActionServlet.
>   Now, the container has a much more flexible mechanism that can work on
> either JSF requests or
>   non-JSF requests.
>

import com.mycompany.mypackage.User;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class LogonCheckFilter implements Filter {

// No initialization required
public void init(FiterConfig config) {}

// No finalization required
public void destroy() {}

// Process each incoming request this filter is mapped to
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {

// Check for a user object in session scope
User user = (User)
  ((HttpServletRequest) request).getSession().getAttribute("user");

// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on

// If the user is not logged on, redirect to the logon page
if (user == null) {
// Do a RequestDispatch.forward() to display the logon page
instead of the requested page
RequestDispatcher rd = ((HttpServletRequest)
request).getRequestDispatcher("/logon.jsp");
rd.forward(request, response);
return;
}

// Otherwise, do the standard processing for this request
chain.doFilter(request, response);

}

}


* By using a JSF PhaseListener to interact with the JSF Lifecycle (which has
> Controller capabilities as well)
>   This is the way most AJAX enabled JSF components interact with the
> server side of their asynchronous
>   requests ... they submit a request to a URL mapped to FacesServlet, and
> a component-provided
>   PhaseListener intercepts control after the Restore View phase has
> completed.  But the point is clear ...
>   the Lifecycle implementation plays a controller role as well, and you
> can customize its behavior with
>   phase listeners quite easily.
>
>
import com.mycompany.mypackage.User;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;

public class LogonCheckListener implements PhaseListener {

// Tell JSF which lifecycle phase(s) we are interested in
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}

// No "before phase" processing required
public void beforePhase(PhaseEvent event) {}

// Perform the logon check after restore view has been completed
public void afterPhase(PhaseEvent event) {

// Check for a user object in session scope
FacesContext context = event.getFacesContext();
User user = (User)
  context.getExternalContext().getSessionMap().get("user");

// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on,
// as well as the restored state of the component tree for the page
that
// is submitting this request, as of the last time it was rendered

// If the user is not logged on, redirect to the logon page
if (user == null) {
// Create the view for the logon page and render it
context.getApplication().getViewHandle().createView
  (context, "/logon.jsp");
context.renderResponse();
return;
}

// Otherwise, do the standard processing for this request
; // No extra processing required

}

}

Both approaches are functionally equivalent, in that (when the user is not
logged on) they bypass the normal form submit processing and cause the logon
page to be rendered instead.  If the user *is* already logged on, the
standard processing proceeds.

Craig

Re: Advice for Struts expert wanting to try Shale?

[Craig McClanahan]

On 1/7/06, Mark Lowe <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > JSF is page centric rather than Action centric.  There is no controller
> as
> > you understand that in Struts with JSF.  JSF is for a tool based, dumbed
> > down, approach: JSF is to Struts as Visual Basic is to C++.
>
> JSF is more page centric than struts, but they aren't chalk and
> cheese. The view controller is still in the backing bean and then
> mapping of outcome to jsp is done via xml configuration. How page or
> controller centric you want jsf to be is upto you, this is where the
> diffence between JSF being a spec and struts a framework start being
> more visible.


If you are familiar with Core J2EE Patterns terminology, you'll find it
easiest to understand JSF and Shale in terms of the View Helper[1] pattern,
where the helper items are the JSF component tags and your backing beans,
and the Dispatcher View[2] pattern, which combines the Front Controller[3]
and View Helper[1] patterns together.  In the Dispatcher View sequence
diagram (Figure 7.25) the roles and responsibilities match up like this:

* Contrroller == FacesServlet

* Dispatcher == the JSF Lifecycle object that manages the request processing
lifecycle

* View == The JSF view (often a JSP page, but not required with things like
Clay or Facelets)

* Helper == The backing bean assocated with the view (in Shale, the
VIewController is a View Helper
  that does more than what you get in pure JSF applications)

In a JSF application, there's actually two ways to implement classic Front
Controller type functionality, such as "send the user to the logon page if
they are not currently logged on":

* With a servlet Filter that gets invoked in front of the JSF controller
(Shale has support for this).  When
  Struts 1.0 was created, there was no such thing, so we had to provide this
capability inside ActionServlet.
  Now, the container has a much more flexible mechanism that can work on
either JSF requests or
  non-JSF requests.

* By using a JSF PhaseListener to interact with the JSF Lifecycle (which has
Controller capabilities as well)
  This is the way most AJAX enabled JSF components interact with the server
side of their asynchronous
  requests ... they submit a request to a URL mapped to FacesServlet, and a
component-provided
  PhaseListener intercepts control after the Restore View phase has
completed.  But the point is clear ...
  the Lifecycle implementation plays a controller role as well, and you can
customize its behavior with
  phase listeners quite easily.


If I was asking how to get started with jsf and shale I'd find your VB
> vs C++ statement confusing and not very helpful at all.


Don't expect much help from someone who doesn't seem to care much for either
JSF or Shale :-).

Mark


Craig

[1] http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
[2]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
[3]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

Re: Advice for Struts expert wanting to try Shale?

[Dakota Jack]

See within:

On 1/7/06, Mark Lowe <[EMAIL PROTECTED]> wrote:


> Both struts and jsf provide a means of handling form submissons, that
> seems pretty view controller to me.



ANY framework has to provide a "means" of handling form submissions.  That
has nothing whatsoever to do with controllers, view controllers, or
whatever.  Check out
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.




> I dont get how everything's so
> black and white and/or chalk and cheese.



I have no idea what this is talking about.  I certainly don't think anyone
who sees what is going on thinks that the controller mechanism in Struts is
anything like that in JSF.  That is a huge confusion that makes no sense.  I
cannot even imagine how one would get to that wrong-headed position.  I do
know that the page-centric boys early on in JSF decided to talk like a view
controller in their scheme of things was like a real controller, but that
was poopooed ad abnitia.



> Sure you define views in jsf,
> and you can mess with more than just the forms, but are the
> differences really as profound or their similarities really comparable
> to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> I get the feeling that I'm being abstracted from the servlet spec.



Apparently you don't know how these things work.  If you did, their huge
differences would be and have to be immediately apparent.



> What IDE vendors do is their affair, they've been trying to make
> coding brain dead for years and I doubt thats going to stop (note: I'm
> not saying that if someone uses an ide s/he is brain dead). But thats
> how JSF and struts are supported by IDE vendors not what they are in
> themselves, is a motorway made with tarmac or cars?



You don't get it, Mark.  VB was made for the IDE vendors and SO WAS JSF, in
order to try a sort of competition with the .NET vendor yearning.  This is
not a case where the IDE people are off on the sidelines playing their own
game.  WIthout the IDE stuff, JSF is pretty much junk.  No one seriously
thinks it is better on the merits of how it works.  At least I hope no one
is that deluded.  It will be better, if at all, based on its ease of use for
people without many skills.



> Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> to get it but I'm not there yet.. While I know there are differences
> between jsf and struts, I dont think they are as profound as you've
> stated.



I think you have to go look at how they are built.  Surely you don't know or
you could not say this, Mark.  They are night and day.  That is not even a
debate in my opinion.  The hope early on was for JSF to obfuscate this
difference so it could purloin the Struts good name.  That worked to a
certain extent.



> > Amen, brother.  I wish Mark would see this.
>
> So do I, I guess I'll have to keep at it, and maybe one day I can
> become just like you :o) More seriously I'd really like what I'm
> missing clarifed as there's obviously something I haven't understood.
>
> Mark



Again, apparently you just don't have a knowledge of the basic workings of
the two frameworks.


On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > Amen, brother.  I wish Mark would see this.
> >
> >
> > On 1/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > > let me assure you VB isnt the only course designed for tech support
> people
> > > wedged between auto-shop and recess
> > > yesterday I was prevented from implementing a script because the
> > individual
> > > didnt want to grant me permissions to the ** directory
> > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > >
> > > Yes I have learned that obfuscation and confusion are more than
> acceptable
> > > substitutes for generating working code
> > >
> > >
> > >
> > > - Original Message -
> > > From: "Mark Lowe" <[EMAIL PROTECTED]>
> > > To: "Struts Users Mailing List" 
> > > Sent: Saturday, January 07, 2006 6:44 AM
> > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > >
> > >
> > > On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > > JSF is page centric rather than Action centric.  There is no
> controller
> > as
> > > > you understand that in Struts with JSF.  JSF is for a tool based,
> dumbed
> > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > >
> > > JSF is more page centric than struts, but they aren't chalk and
> > > cheese. The view controller is still in the backing bean and then
> > > mapping of outcome to jsp is done via xml configuration. How page or
> > > controller centric you want jsf to be is upto you, this is where the
> > > diffence between JSF being a spec and struts a framework start being
> > > more visible.
> > >
> > > If I was asking how to get started with jsf and shale I'd find your VB
> > > vs C++ statement confusing and not very helpful at all.
> > >
> > > Mark
> > >
> > > >
> > > > On 1/6/06, Rick Mann < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Thanks for

Re: [JSF/Shale] bean:message with parameter

[Craig McClanahan]

On 1/7/06, Garner, Shawn <[EMAIL PROTECTED]> wrote:
>
> I want to do something like this in JSF:
> 
>
> Which I think translates to
>
> 
>   
> 



Is this correct?


Almost ... first, try it with  instead of .
And, if you've loaded message bundles that have keys with periods in them,
here's a trick that will simplify your life:

  

  


Shawn


Craig

Re: Advice for Struts expert wanting to try Shale?

[Frank W. Zammetti]

Ted Husted wrote:

An expert uses the best tool for the job. A journeyman wants one size
to fit all.


Blessed are those who get to make such decisions.  There are 
unfortunately many shops that decide what the proper technologies are 
*before* any project kicks off, all in the name of "standardization".


Frank

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

RE: The framework I think I want...

[Daniel Blumenthal]

Frank,

> Interesting... there is of course no reason you can't use 
> ActionForms with AJAX, was it a conscious decision that you 
> didn't need them?  How 
> are you getting around not using them?   Your Actions pull parameters 
> directly from request I assume?

Right.  My struts-config.xml file is basically divided into three sections,
as follows.

Setup actions:





File mappings:



AJAX actions (all handled by one Action):





To send AJAX commands, I use JavaScript to construct an appropriate
URL/query string, then send using the standard XMLHttpRequest code.  Inside
the CommandAction class, I figure out which command was called
(request.getServletPath()), call the matching function, and use
request.getParameter() to get the parameters specific to the command.

> > Any thoughts on JSTL?  Must have?  Nice but not necessary?
> 
> I just started using JSTL fairly recently, but I would highly 
> recommend doing so.  I guess I'd say VERY nice, but not 
> necessary.  However, I will say this... if you are thinking 
> of using the Struts taglibs, aside from HTML, I think the 
> better option by far is using JSTL.  The HTML taglib still 
> has a place, but the others I consider deprecated in favor of JSTL.
> 
> Then again, if your building RIAs with Struts, my opinion is 
> that the HTML taglib will get in your way far more than it 
> will help anyway... 
> That's another thread though :)

Very interesting - now that I'm not using ActionForms (to repeat - not a
conscious decision, but the way things seem to be turning out), I find
myself only using tiles, logic, and bean tags.  So, everything *but* html.
I'll definitely give JSTL a hard look.

Oh, and I use sslext.  Is this still necessary in 1.2.8?  In 1.3?

Daniel



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

Re: Advice for Struts expert wanting to try Shale?

[Ted Husted]

On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
> If you don't believe me, you can look in the famous pattern books out
> there (Fowler, J2EE core patterns).

Some of which used Struts as one of the use cases to prove a pattern exists. :)

But, in the end, it is what it is. What we call a mechanism is not as
important as whether the mechanism suits a developer's needs.
Sometimes JSF will work well for an application. Sometimes it won't.
An expert uses the best tool for the job. A journeyman wants one size
to fit all.

Another example is SQL data mappers verus object relational mappers.
Sometimes, iBATIS is the best tool for the job. Sometimes Cayene or
Hibernate work even better.

-Ted.

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

Re: Advice for Struts expert wanting to try Shale?

[Alexandre Poitras]

By the way the so called application controller (RequestProcessor)
pattern has NOTHING to do with the controller (action, backing bean),
also called input controller, found in the so often misunderstood MVC
pattern. The only similarity is the sharing of the term controller.
If you don't believe me, you can look in the famous pattern books out
there (Fowler, J2EE core patterns). So Dakota your argument doesn't
make any senses to me unless you clarify wich controller you talk
about...

On 1/7/06, Mark Lowe <[EMAIL PROTECTED]> wrote:
> Both struts and jsf provide a means of handling form submissons, that
> seems pretty view controller to me. I dont get how everything's so
> black and white and/or chalk and cheese. Sure you define views in jsf,
> and you can mess with more than just the forms, but are the
> differences really as profound or their similarities really comparable
> to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> I get the feeling that I'm being abstracted from the servlet spec.
>
> What IDE vendors do is their affair, they've been trying to make
> coding brain dead for years and I doubt thats going to stop (note: I'm
> not saying that if someone uses an ide s/he is brain dead). But thats
> how JSF and struts are supported by IDE vendors not what they are in
> themselves, is a motorway made with tarmac or cars?
>
> Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> to get it but I'm not there yet.. While I know there are differences
> between jsf and struts, I dont think they are as profound as you've
> stated.
>
> > Amen, brother.  I wish Mark would see this.
>
> So do I, I guess I'll have to keep at it, and maybe one day I can
> become just like you :o) More seriously I'd really like what I'm
> missing clarifed as there's obviously something I haven't understood.
>
> Mark
>
> On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > Amen, brother.  I wish Mark would see this.
> >
> >
> > On 1/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > > let me assure you VB isnt the only course designed for tech support people
> > > wedged between auto-shop and recess
> > > yesterday I was prevented from implementing a script because the
> > individual
> > > didnt want to grant me permissions to the ** directory
> > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > >
> > > Yes I have learned that obfuscation and confusion are more than acceptable
> > > substitutes for generating working code
> > >
> > >
> > >
> > > - Original Message -
> > > From: "Mark Lowe" <[EMAIL PROTECTED]>
> > > To: "Struts Users Mailing List" 
> > > Sent: Saturday, January 07, 2006 6:44 AM
> > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > >
> > >
> > > On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > > JSF is page centric rather than Action centric.  There is no controller
> > as
> > > > you understand that in Struts with JSF.  JSF is for a tool based, dumbed
> > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > >
> > > JSF is more page centric than struts, but they aren't chalk and
> > > cheese. The view controller is still in the backing bean and then
> > > mapping of outcome to jsp is done via xml configuration. How page or
> > > controller centric you want jsf to be is upto you, this is where the
> > > diffence between JSF being a spec and struts a framework start being
> > > more visible.
> > >
> > > If I was asking how to get started with jsf and shale I'd find your VB
> > > vs C++ statement confusing and not very helpful at all.
> > >
> > > Mark
> > >
> > > >
> > > > On 1/6/06, Rick Mann < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > > > authority :-). Questions below...
> > > > >
> > > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > > >
> > > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > > that has
> > > > > > been out for nearly two years now.  A good starting place for
> > > > > > general JSF
> > > > > > knowledge and information is .  Kito does a
> > > > > > good job
> > > > > > of staying on top of the most recent articles and items of
> > > > > > interest.  This,
> > > > > > by the way, is *exactly* the place to start before looking much at
> > > > > > Shale
> > > > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > > > and what
> > > > > > it brings to the table all by itself, because it focuses on adding
> > > > > > value
> > > > > > around the edges.  Without understanding those edges a little, it's
> > > > > > harder
> > > > > > to appreciate the benefits :-).
> > > > >
> > > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > > enough for me to build on.
> > > > >
> > > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > > part of Struts? I'm still terribly unfamiliar with the

Re: The framework I think I want...

[Frank W. Zammetti]

Daniel Blumenthal wrote:

I hadn't really thought about it, but looking at the code which has already
been written for "version 2" of my site, I noticed that I haven't used any
ActionForms (yet).  Everything is being communicated via AJAX, and I just
haven't needed any.  So it's interesting to hear that other people are
moving away from them (even if for entirely different reasons).


Interesting... there is of course no reason you can't use ActionForms 
with AJAX, was it a conscious decision that you didn't need them?  How 
are you getting around not using them?   Your Actions pull parameters 
directly from request I assume?


I've discussed with a few people the idea of developing an entirely new 
framework that is specifically geared to writing RIAs, and I've 
prototyped a few ideas, but honestly, none of it has been significantly 
different than what we have already, which has dissuaded me from going 
at it full-bore.  I think the basic idea is worth persuing though... a 
framework whos purpose in life is to build the kinds of apps we're 
starting to see more and more of, rather than trying to do them with 
frameworks that aren't really geared towards that.  This is at least 
part of the promise of JSF, but even that I feel tries to cater to the 
more "typical" web development, and in doing so isn't the right 
direction as far as what I'm talking about goes.



Any thoughts on JSTL?  Must have?  Nice but not necessary?


I just started using JSTL fairly recently, but I would highly recommend 
doing so.  I guess I'd say VERY nice, but not necessary.  However, I 
will say this... if you are thinking of using the Struts taglibs, aside 
from HTML, I think the better option by far is using JSTL.  The HTML 
taglib still has a place, but the others I consider deprecated in favor 
of JSTL.


Then again, if your building RIAs with Struts, my opinion is that the 
HTML taglib will get in your way far more than it will help anyway... 
That's another thread though :)



Daniel


Frank

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

RE: The framework I think I want...

[Daniel Blumenthal]

I just wanted to say, this has been a great thread, and given me a lot of
food for thought.  As I mentioned previously, I've spent a lot of time with
my head down developing in Struts 1.1, and now that I'm refactoring my site,
it's good to hear people batting around different ideas about the different
weaknesses/strengths of the various frameworks.

I hadn't really thought about it, but looking at the code which has already
been written for "version 2" of my site, I noticed that I haven't used any
ActionForms (yet).  Everything is being communicated via AJAX, and I just
haven't needed any.  So it's interesting to hear that other people are
moving away from them (even if for entirely different reasons).

Any thoughts on JSTL?  Must have?  Nice but not necessary?

Daniel



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

Re: Advice for Struts expert wanting to try Shale?

[Mark Lowe]

Both struts and jsf provide a means of handling form submissons, that
seems pretty view controller to me. I dont get how everything's so
black and white and/or chalk and cheese. Sure you define views in jsf,
and you can mess with more than just the forms, but are the
differences really as profound or their similarities really comparable
to VB and C++? Sorry I dont get it. When coding jsf and struts struff
I get the feeling that I'm being abstracted from the servlet spec.

What IDE vendors do is their affair, they've been trying to make
coding brain dead for years and I doubt thats going to stop (note: I'm
not saying that if someone uses an ide s/he is brain dead). But thats
how JSF and struts are supported by IDE vendors not what they are in
themselves, is a motorway made with tarmac or cars?

Like i said before, C++ and VB like struts and jsf, sorry I'm trying
to get it but I'm not there yet.. While I know there are differences
between jsf and struts, I dont think they are as profound as you've
stated.

> Amen, brother.  I wish Mark would see this.

So do I, I guess I'll have to keep at it, and maybe one day I can
become just like you :o) More seriously I'd really like what I'm
missing clarifed as there's obviously something I haven't understood.

Mark

On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Amen, brother.  I wish Mark would see this.
>
>
> On 1/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > let me assure you VB isnt the only course designed for tech support people
> > wedged between auto-shop and recess
> > yesterday I was prevented from implementing a script because the
> individual
> > didnt want to grant me permissions to the ** directory
> > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> >
> > Yes I have learned that obfuscation and confusion are more than acceptable
> > substitutes for generating working code
> >
> >
> >
> > - Original Message -
> > From: "Mark Lowe" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" 
> > Sent: Saturday, January 07, 2006 6:44 AM
> > Subject: Re: Advice for Struts expert wanting to try Shale?
> >
> >
> > On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > JSF is page centric rather than Action centric.  There is no controller
> as
> > > you understand that in Struts with JSF.  JSF is for a tool based, dumbed
> > > down, approach: JSF is to Struts as Visual Basic is to C++.
> >
> > JSF is more page centric than struts, but they aren't chalk and
> > cheese. The view controller is still in the backing bean and then
> > mapping of outcome to jsp is done via xml configuration. How page or
> > controller centric you want jsf to be is upto you, this is where the
> > diffence between JSF being a spec and struts a framework start being
> > more visible.
> >
> > If I was asking how to get started with jsf and shale I'd find your VB
> > vs C++ statement confusing and not very helpful at all.
> >
> > Mark
> >
> > >
> > > On 1/6/06, Rick Mann < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > > authority :-). Questions below...
> > > >
> > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > >
> > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > that has
> > > > > been out for nearly two years now.  A good starting place for
> > > > > general JSF
> > > > > knowledge and information is .  Kito does a
> > > > > good job
> > > > > of staying on top of the most recent articles and items of
> > > > > interest.  This,
> > > > > by the way, is *exactly* the place to start before looking much at
> > > > > Shale
> > > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > > and what
> > > > > it brings to the table all by itself, because it focuses on adding
> > > > > value
> > > > > around the edges.  Without understanding those edges a little, it's
> > > > > harder
> > > > > to appreciate the benefits :-).
> > > >
> > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > enough for me to build on.
> > > >
> > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > > website.
> > > >
> > > > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > > > is there some other way to get site L&F re-use?
> > > >
> > > > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > > > yet.  One
> > > > > high level overview is the session I did at ApacheCon (reprised
> > > > > from one
> > > > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > > > little
> > > > > in the translation without the corresponding demo program, which is
> > > > > not in a
> > > > > shape that I'm quite ready to check in yet :-).
> > > >
> > > > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > > > work it in easily eno

Re: [Shale] getting my first dialog to work with Shale/MyFaces

[gramani]

Rahul Akolkar <[EMAIL PROTECTED]> wrote on 01/06/2006 05:07:21 PM:

> On 1/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> >
> > Actually I found that dialog-config.xml had an xml error so I guess it 
was
> > silently not loaded. So I fixed it and now the Cancel works (yeahh!!) 
so I
> > think at least I have gotten "into the dialog..:) My "Search" still 
throws
> > a nasty error, but I guess I shall struggle with that awhile before I 
give
> > up and ask you again..(:(
> >
> 
> 
> Possibly rethink the corresponding outbound transition from the
> SearchHome view state (separate the search and results views).

Thank you Rahul. Actually the specs are that my results appear just below 
my search form and I had already coded things so everything was in 
/search.jsp (I used rendered attributes to render results if present). 
However I guess what Shale requires is for the ids (names) to be different 
(and never mind what those names map to). So that's what i did:


 
 


 

 




 


This worked for my *first* search: my searchBean.find() returns "
ContactListSuccess" and everything is hunky dory. Sweet. *However*, since 
my search form is visble above my results, I got a Faces error when I 
searched again! And the error made sense too (;) since I was in the 
"ContactListSuccess" state (after the first successful search) and I was 
now transitioning to "ContactSearchSuccess" again due to the second 
search, which is not a legal outcome according to the dialog. So I moved 
the  up 
so it was a common transition (instead of adding it twice) and then I no 
longer got the error. 

Furthermore, my menu bar, which is always visible and which has a link to 
dialog:Search Contacts also is always clickable. Thus I also need a common 
transition for outcome "Search Contacts". So my dialog now looks like 
this:





 
 
 

 

 

 





I do have a few more transitions which I have omitted (which are not 
common), but it really seems to me that by making so many of the 
transitions "common", I am not utilizing what Shale can give me via 
dialogs. Is this correct? Or is this what i have to live with since my 
specs dictate I show the search form above my results and I always have 
the menu bar visible? I get the feeling I may be missing something 
important..

> 
> -Rahul

Once again thank you for your time and patience!
Geeta

RE: Calendar Project

[Jim Douglas]

I couldn't find one, but this PHP based one will integrate with STRUTS,

http://www.k5n.us/webcalendar.php

You can use this PHP - JAVA bridge
http://php-java-bridge.sourceforge.net/

(of course you have to have PHP installed first)

Jim


From: Rafael Taboada <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" 
To: Struts List 
Subject: Calendar Project
Date: Fri, 6 Jan 2006 22:40:32 -0500

Please. Do u know a calendar project made in struts??? I mean, when u make
an appointemnt, an event
thanks

--
Rafael Taboada
Software Engineer

Cell : +511-97753290

"No creo en el destino pues no me gusta tener la idea de controlar mi vida"




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

[JSF/Shale] bean:message with parameter

[Garner, Shawn]

I want to do something like this in JSF:


Which I think translates to 


  


Is this correct?

Shawn

 
This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 


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

Re: Redirection

[Niall Pemberton]

Currently (i.e. Struts 1.2.x) this is done in the processForwardConfig()
method of the RequestProcessor - if the ActionMapping has "redirect" set to
true it calls the sendRedirect(url) method - which as I understand it is a
convenience method for setting a "302" status and "location" header.

Currently you would have to create your own custom RequestProcessor to
achieve this and override the processForwardConfig() method to do this.

Not sure about "isPermanent" - looks like there are a number of
"redirection" status codes according to the spec - 301/302/303/307

ftp://ftp.isi.edu/in-notes/rfc2616.txt


Niall

- Original Message - 
From: "Dakota Jack" <[EMAIL PROTECTED]>
Sent: Saturday, January 07, 2006 3:06 PM


Hi, Eric,

I think you have to go back through the code and find out where the status
codes are handled.  I have to admit that I don't know.  If someone else
does, this would be great information to have.  This is an interesting
problem and one that I always put on the back burner.  Maybe now is the time
to make some decisions about what to do.



On 1/7/06, Eric Jain <[EMAIL PROTECTED]> wrote:
>
> Mark Lowe wrote:
> > Not sure if i've understood what you're after, but you can just write
> > to the reponse (as you would in a normal servlet) and return null for
> > you action forward. Your webapp configuration will do the rest from
> > there like with any webapp.
>
> Yes, that's a solution. On the other hand ActionForwards are convenient to
> use (no need to worry about paths etc.), so I was wondering if you could
> do
> something like:
>
>forward.setRedirect(true); // existing method
>forward.setPermanent(true); // possible extension?
>
> I know it is possible to implement your own ActionForward classes, but I'm
> not sure that would help here. Ideally the RequestProcessor would ask the
> ActionForward for a status code at one point...
>
> -
> 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: How to forward from one action to another, with modified parameters?

[Dakota Jack]

In my opinion, Eric, this is a bad solution.  There are lots of reasons this
is bad.  Rather than go through them, I would suggest you just add the logic
in /search.do?query=42 at the point you get the failure form
/retrieve.do?id=42.

On 1/7/06, Eric Jain <[EMAIL PROTECTED]> wrote:
>
> If a request for
>
>/retrieve.do?id=42
>
> fails (e.g. couldn't find item in database), I'd like to say
>
>request.setStatus(HttpServletResponse.SC_NOT_FOUND);
>request.setAttribute("warning", "Not your lucky day.");
>
> and forward (not redirect) the request to
>
>/search.do?query=42
>
> Can this behavior be accomplishing with Struts? Currently I'm using
> request.getRequestDispatcher(...).forward(...) with a modified
> HttpServletRequest, but there must be a better way (TM)...
>
> -
> 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~

Re: Redirection

[Dakota Jack]

Hi, Eric,

I think you have to go back through the code and find out where the status
codes are handled.  I have to admit that I don't know.  If someone else
does, this would be great information to have.  This is an interesting
problem and one that I always put on the back burner.  Maybe now is the time
to make some decisions about what to do.



On 1/7/06, Eric Jain <[EMAIL PROTECTED]> wrote:
>
> Mark Lowe wrote:
> > Not sure if i've understood what you're after, but you can just write
> > to the reponse (as you would in a normal servlet) and return null for
> > you action forward. Your webapp configuration will do the rest from
> > there like with any webapp.
>
> Yes, that's a solution. On the other hand ActionForwards are convenient to
> use (no need to worry about paths etc.), so I was wondering if you could
> do
> something like:
>
>forward.setRedirect(true); // existing method
>forward.setPermanent(true); // possible extension?
>
> I know it is possible to implement your own ActionForward classes, but I'm
> not sure that would help here. Ideally the RequestProcessor would ask the
> ActionForward for a status code at one point...
>
> -
> 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~

Re: Advice for Struts expert wanting to try Shale?

[Dakota Jack]

The view "controller" is not a controller in the Web-MVC sense and is
completely misleading, in my opinion, Mark.  So part of this just may be
who's dog is in the hunt?

The point of the tool-based and VB analogy is that JSF tries to hide from
you, to do it for you, what other frameworks, like Struts, demand you know.
This allows quick turnaround and allows the construction of tools.  This was
the charter for JSF.  It is not a bug, it is deliberate.  So, if this
confuses a new person, at least it has the value of being accurate as hell.
So, if you want to use programmers with little experience and train them to
use the inevitable tools, just like with the community college VB junkies,
JSF is a good alternative.  If you think a smaller cadre of thinking and
knowing engineers is the way to go, like cs graduates who know Java or C++,
then Struts is the way to go.

JSF is not more page centric than Struts.  JSF is page centric.  Struts is
not page centric.

Something has to take JSF from page to page, and this is called a "view
controller" due to an unfortunate naming of a pattern having to do with
views, pages.  This, again, is NOT a controller as you find in Struts.

I personally would find my VB and C++ the most helpful.  I always find
heuristics the most helpful, unless you want to get bogged down in
irrelevant detail, like "view controller".  This is essentially the sort of
choice you are making.  VB is a tool based, dumbed down, "language".  JSF is
a tool based, dumbed down "framework".  C++ is a full blown language.
Struts is a full blown framework.



On 1/7/06, Mark Lowe <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > JSF is page centric rather than Action centric.  There is no controller
> as
> > you understand that in Struts with JSF.  JSF is for a tool based, dumbed
> > down, approach: JSF is to Struts as Visual Basic is to C++.
>
> JSF is more page centric than struts, but they aren't chalk and
> cheese. The view controller is still in the backing bean and then
> mapping of outcome to jsp is done via xml configuration. How page or
> controller centric you want jsf to be is upto you, this is where the
> diffence between JSF being a spec and struts a framework start being
> more visible.
>
> If I was asking how to get started with jsf and shale I'd find your VB
> vs C++ statement confusing and not very helpful at all.
>
> Mark
>
> >
> > On 1/6/06, Rick Mann <[EMAIL PROTECTED]> wrote:
> > >
> > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > authority :-). Questions below...
> > >
> > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > >
> > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > that has
> > > > been out for nearly two years now.  A good starting place for
> > > > general JSF
> > > > knowledge and information is .  Kito does a
> > > > good job
> > > > of staying on top of the most recent articles and items of
> > > > interest.  This,
> > > > by the way, is *exactly* the place to start before looking much at
> > > > Shale
> > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > and what
> > > > it brings to the table all by itself, because it focuses on adding
> > > > value
> > > > around the edges.  Without understanding those edges a little, it's
> > > > harder
> > > > to appreciate the benefits :-).
> > >
> > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > enough for me to build on.
> > >
> > > A question comes up: what has happened to Tiles? Is it no longer a
> > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > website.
> > >
> > > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > > is there some other way to get site L&F re-use?
> > >
> > > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > > yet.  One
> > > > high level overview is the session I did at ApacheCon (reprised
> > > > from one
> > > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > > little
> > > > in the translation without the corresponding demo program, which is
> > > > not in a
> > > > shape that I'm quite ready to check in yet :-).
> > >
> > > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > > work it in easily enough when the time comes.
> > >
> > >
> > > Here's my big question: do I still think in terms of Struts Actions
> > > handling the business logic of my application (which they rarely do;
> > > they usually glue to the "real" biz code)? Or do I look to putting
> > > all that glue within JSF controllers?
> > >
> > > Thanks!
> > >
> > > --
> > > Rick
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > "You can lead a horse to water but you cannot ma

Re: Redirection

[Eric Jain]

Mark Lowe wrote:

Not sure if i've understood what you're after, but you can just write
to the reponse (as you would in a normal servlet) and return null for
you action forward. Your webapp configuration will do the rest from
there like with any webapp.


Yes, that's a solution. On the other hand ActionForwards are convenient to 
use (no need to worry about paths etc.), so I was wondering if you could do 
something like:


  forward.setRedirect(true); // existing method
  forward.setPermanent(true); // possible extension?

I know it is possible to implement your own ActionForward classes, but I'm 
not sure that would help here. Ideally the RequestProcessor would ask the 
ActionForward for a status code at one point...


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

Re: Redirection

[Mark Lowe]

Not sure if i've understood what you're after, but you can just write
to the reponse (as you would in a normal servlet) and return null for
you action forward. Your webapp configuration will do the rest from
there like with any webapp.

On 1/7/06, Eric Jain <[EMAIL PROTECTED]> wrote:
> Is there any way I could get an ActionForward to do permanent (301) rather
> than temporary (302) redirects?
>
> -
> 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]

Redirection

[Eric Jain]

Is there any way I could get an ActionForward to do permanent (301) rather 
than temporary (302) redirects?


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

How to forward from one action to another, with modified parameters?

[Eric Jain]

If a request for

  /retrieve.do?id=42

fails (e.g. couldn't find item in database), I'd like to say

  request.setStatus(HttpServletResponse.SC_NOT_FOUND);
  request.setAttribute("warning", "Not your lucky day.");

and forward (not redirect) the request to

  /search.do?query=42

Can this behavior be accomplishing with Struts? Currently I'm using 
request.getRequestDispatcher(...).forward(...) with a modified 
HttpServletRequest, but there must be a better way (TM)...


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

Re: Advice for Struts expert wanting to try Shale?

[Mark Lowe]

On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> JSF is page centric rather than Action centric.  There is no controller as
> you understand that in Struts with JSF.  JSF is for a tool based, dumbed
> down, approach: JSF is to Struts as Visual Basic is to C++.

JSF is more page centric than struts, but they aren't chalk and
cheese. The view controller is still in the backing bean and then
mapping of outcome to jsp is done via xml configuration. How page or
controller centric you want jsf to be is upto you, this is where the
diffence between JSF being a spec and struts a framework start being
more visible.

If I was asking how to get started with jsf and shale I'd find your VB
vs C++ statement confusing and not very helpful at all.

Mark

>
> On 1/6/06, Rick Mann <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for the response, Craig. It's nice to get an answer from THE
> > authority :-). Questions below...
> >
> > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> >
> > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > that has
> > > been out for nearly two years now.  A good starting place for
> > > general JSF
> > > knowledge and information is .  Kito does a
> > > good job
> > > of staying on top of the most recent articles and items of
> > > interest.  This,
> > > by the way, is *exactly* the place to start before looking much at
> > > Shale
> > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > and what
> > > it brings to the table all by itself, because it focuses on adding
> > > value
> > > around the edges.  Without understanding those edges a little, it's
> > > harder
> > > to appreciate the benefits :-).
> >
> > Okay, I'll try to find a "hello world" JSF example. That might be
> > enough for me to build on.
> >
> > A question comes up: what has happened to Tiles? Is it no longer a
> > part of Struts? I'm still terribly unfamiliar with the new Struts
> > website.
> >
> > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > is there some other way to get site L&F re-use?
> >
> > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > yet.  One
> > > high level overview is the session I did at ApacheCon (reprised
> > > from one
> > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > little
> > > in the translation without the corresponding demo program, which is
> > > not in a
> > > shape that I'm quite ready to check in yet :-).
> >
> > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > work it in easily enough when the time comes.
> >
> >
> > Here's my big question: do I still think in terms of Struts Actions
> > handling the business logic of my application (which they rarely do;
> > they usually glue to the "real" biz code)? Or do I look to putting
> > all that glue within JSF controllers?
> >
> > Thanks!
> >
> > --
> > Rick
> >
> >
> >
> > -
> > 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~
>
>

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

Re: Advice for Struts expert wanting to try Shale?

[Dakota Jack]

JSF is page centric rather than Action centric.  There is no controller as
you understand that in Struts with JSF.  JSF is for a tool based, dumbed
down, approach: JSF is to Struts as Visual Basic is to C++.

On 1/6/06, Rick Mann <[EMAIL PROTECTED]> wrote:
>
> Thanks for the response, Craig. It's nice to get an answer from THE
> authority :-). Questions below...
>
> On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
>
> > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > that has
> > been out for nearly two years now.  A good starting place for
> > general JSF
> > knowledge and information is .  Kito does a
> > good job
> > of staying on top of the most recent articles and items of
> > interest.  This,
> > by the way, is *exactly* the place to start before looking much at
> > Shale
> > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > and what
> > it brings to the table all by itself, because it focuses on adding
> > value
> > around the edges.  Without understanding those edges a little, it's
> > harder
> > to appreciate the benefits :-).
>
> Okay, I'll try to find a "hello world" JSF example. That might be
> enough for me to build on.
>
> A question comes up: what has happened to Tiles? Is it no longer a
> part of Struts? I'm still terribly unfamiliar with the new Struts
> website.
>
> Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> is there some other way to get site L&F re-use?
>
> > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > yet.  One
> > high level overview is the session I did at ApacheCon (reprised
> > from one
> > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > little
> > in the translation without the corresponding demo program, which is
> > not in a
> > shape that I'm quite ready to check in yet :-).
>
> Okay, I'll hold off worrying about Shale for now. Sounds like I can
> work it in easily enough when the time comes.
>
>
> Here's my big question: do I still think in terms of Struts Actions
> handling the business logic of my application (which they rarely do;
> they usually glue to the "real" biz code)? Or do I look to putting
> all that glue within JSF controllers?
>
> Thanks!
>
> --
> Rick
>
>
>
> -
> 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~

Re: The framework I think I want...

[Dakota Jack]

Again, it was not a challenge.  Thanks for explaining.

On 1/6/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> Its a valid point - I did vote for WebWork without much knowledge and
> anyone
> crticising my decision to do that probably has good grounds to do so. For
> the record the following was my response on the PMC list to the proposal
> to
> merge with WebWork.
>
>  quote 
> "I like this idea and  prefer it to Clarity. IMO a true merger of projects
> is
> the only way we might successfully pool resources and stop competing.
> Clarity is a good concept, but I don't believe it would be possible to
> keep
> everyone on board and prevent communities splitting. I have no real
> knowledge of WebWork, but it has a good reputation and I dabbled around in
> the source code a week or so ago and liked what I saw. I also think if
> Spring are involved then things are going to go badly - that may be an
> unfair criticism, but its my gut feeling.
>
> I don't have the time or ability to be driving Struts forward with major
> contributions or re-writes of the existing framework, but I am happy
> carrying on with smaller contributions and support -so pooling resources
> this way is IMO a good thing. It would be good to get to know the people
> from these other projects a bit better - I went to Eddie O'Neil's
> presentation at BeaWorld recently, but the others I know nothing about.
> Are
> any of them going to ApacheCon?"
>
>  end quote 
>
> Niall
>
> - Original Message -
> From: "Dakota Jack" <[EMAIL PROTECTED]>
> Sent: Friday, January 06, 2006 11:59 PM
>
>
> I am confused (there's an opening for those that like them): did you not
> vote for WebWorks, Niall?  If so, how could it be that this education is
> happening now?  That's not a challenge so please don't take it as one, but
> a
> curious question as to what is going on.
>
>
>
> -
> 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~