Re: Basic Dialog Manager
Hi. I had the same problem with the BasicLifecycleListener. I drilled it down to be a problem of the WTP Tomcat integration within Eclipse. Are you using WTP or plain tomcat? /Veit Original-Nachricht Datum: Wed, 11 Apr 2007 18:43:41 +0200 Von: Matthias Wuttke <[EMAIL PROTECTED]> An: [EMAIL PROTECTED] Betreff: Basic Dialog Manager > Hi! > > I am trying to use the Basic Dialog Manager. I noticed the following: > > - If you only include shale-dialog (and not shale-dialog-basic) as a > dependency, you will get a NullPointerException in > DialogNavigationHandler:121. A more meaningful error message would be > helpful. > > - After including shale-dialog-basic, I got a NullPointerException in > BasicDialogManager:97. It seems the dialog map is not added to the > application scope. Again, I would like to suggest providing a more > meaningful error message. > > - I have got a WEB-INF/dialog-config.xml file, but it does not seem to > be parsed. I resolved this to be an issue with the servlet container I > am using (Winstone) -- it does not honor the BasicLifecycleListener. > > I have got some questions: > > - I'd like to be able to use something like in the > faces-config.xml navigation case definitions. Is there a way to specify > this for view transitions? > > - I'd like to pass GET parameters between the dialog pages. Is it > possible to use EL expressions in the viewId attributes? Please compare > to: > http://typo.ars-subtilior.com/articles/2007/01/24/how-to-make-jsf-navigation-rules-more-dynamic > > Thank you very much for this great framework! > > Best regards, > Matthias -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: SV: SV: Re: basic dialog nullpointerexception
My project needs Java5, so it wouldn't be a solution for me... Original-Nachricht Datum: Thu, 15 Mar 2007 05:28:24 +0100 Von: Hermod Opstvedt <[EMAIL PROTECTED]> An: user@shale.apache.org CC: Betreff: SV: SV: Re: basic dialog nullpointerexception > Hi > > Try it with jdk 1.4 on 5.5.23 and see what happens then. > > Hermod > > > -----Opprinnelig melding- > Fra: Veit Guna [mailto:[EMAIL PROTECTED] > Sendt: 14. mars 2007 23:06 > Til: user@shale.apache.org > Emne: Re: SV: Re: basic dialog nullpointerexception > > Hi. > > After I switched my local project to another version (different > workspace), it indeeded stopped working with 5.5.23. But it worked > before with 5.5.23. I don't know what it blew up. > > So that means, listeners in tlds only work up to tomcat 5.5.17? But it > didn't work out with my 5.5.17 version. Strange thing. Meanwhile I think > perhaps it's a problem with eclipse wtp and tomcat. Never tried it with > tomcat standalone. Did you? > > BTW: I'm using Java5. > > regards, > Veit > > > Hermod Opstvedt schrieb: > > Hi > > > > The last working version of Tomcat is actually 5.5.17 with Java5. If you > > switch to Java 1.4 things are different. > > > > There is a post by me on this, where I went through and tested on all > 5.5.x > > versions, and things stopped working after 5.5.17 > > > > Hermod > > > > > > -Opprinnelig melding- > > Fra: Veit Guna [mailto:[EMAIL PROTECTED] > > Sendt: 12. mars 2007 20:34 > > Til: user@shale.apache.org > > Emne: SV: Re: basic dialog nullpointerexception > > > > Hi again. > > > > I upgraded my Tomcat 5.5.17 installation (it wasn't 5.5.16) to tomcat > 5.5.23 > > and now the BasicLifecycleListener gets invoked. > > > > Seemed to be a problem with tomcat?! > > > > Regards, > > Veit > > > > > > Original-Nachricht > > Datum: Mon, 12 Mar 2007 13:41:26 +0100 > > Von: "Veit Guna" <[EMAIL PROTECTED]> > > An: user@shale.apache.org > > CC: > > Betreff: Re: basic dialog nullpointerexception > > > >> I'm using tomcat 5.5.16. > >> > >> > >> Original-Nachricht > >> Datum: Mon, 12 Mar 2007 05:31:50 -0700 > >> Von: "Craig McClanahan" <[EMAIL PROTECTED]> > >> An: user@shale.apache.org > >> CC: > >> Betreff: Re: basic dialog nullpointerexception > >> > >>> On 3/12/07, Veit Guna <[EMAIL PROTECTED]> wrote: > >>>> Hi. > >>>> > >>>> I'm trying to get the basic dialog feature of shale 1.0.4 working. > >> I've > >>> added the jars view, dialog, basic-dialog, core to my classpath and > >> created > >>> a dialog xml file in WEB-INF. Now when I try in a h:commandLink an > >> action > >>> like "dialog:myDialog" a NullPointerException occurs: > >>>> java.lang.NullPointerException > >>>>at > >>>> > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j > > ava:97) > >>>>at > >>>> > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j > > ava:87) > >>>>at > >>>> > > > org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(Dialo > > gNavigationHandler.java:121) > >>>>at > >>>> > > > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListen > > erImpl.java:84) > >>>>at > >>>> > > > org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListe > > ner.java:74) > >>>>at > >>>> ... > >>>> > >>>> I've taken a look at the BasicDialogManager. It tries to use an > >>> uninitialized Map. I guess it should be initialized by the > >> BasicLifecycleListener > >>> but it isn't. Any hints, what I've forgotten? > >>>> Do I have to put the BasicLifecycleListener somewhere manually? > >>> In general, you should *not* have to configure this listener manually. > >>> It is registered in a listener defined in the > >>> shale-dialog-basic-xxx.jar file that you're including. However, not > >>> all containers properly implement registering listeners in a TLD > >>> inside a JAR file. What container and version are you running on? > >>> > >>> Craig > >>> > >>>> Regards, > >>>> Veit > >>>> > >>>> -- > >>>> "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > >>>> Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out > >>>> > >> -- > >> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > >> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > > -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out
Re: SV: Re: basic dialog nullpointerexception
Hi. After I switched my local project to another version (different workspace), it indeeded stopped working with 5.5.23. But it worked before with 5.5.23. I don't know what it blew up. So that means, listeners in tlds only work up to tomcat 5.5.17? But it didn't work out with my 5.5.17 version. Strange thing. Meanwhile I think perhaps it's a problem with eclipse wtp and tomcat. Never tried it with tomcat standalone. Did you? BTW: I'm using Java5. regards, Veit Hermod Opstvedt schrieb: > Hi > > The last working version of Tomcat is actually 5.5.17 with Java5. If you > switch to Java 1.4 things are different. > > There is a post by me on this, where I went through and tested on all 5.5.x > versions, and things stopped working after 5.5.17 > > Hermod > > > -Opprinnelig melding- > Fra: Veit Guna [mailto:[EMAIL PROTECTED] > Sendt: 12. mars 2007 20:34 > Til: user@shale.apache.org > Emne: SV: Re: basic dialog nullpointerexception > > Hi again. > > I upgraded my Tomcat 5.5.17 installation (it wasn't 5.5.16) to tomcat 5.5.23 > and now the BasicLifecycleListener gets invoked. > > Seemed to be a problem with tomcat?! > > Regards, > Veit > > > Original-Nachricht > Datum: Mon, 12 Mar 2007 13:41:26 +0100 > Von: "Veit Guna" <[EMAIL PROTECTED]> > An: user@shale.apache.org > CC: > Betreff: Re: basic dialog nullpointerexception > >> I'm using tomcat 5.5.16. >> >> >> Original-Nachricht >> Datum: Mon, 12 Mar 2007 05:31:50 -0700 >> Von: "Craig McClanahan" <[EMAIL PROTECTED]> >> An: user@shale.apache.org >> CC: >> Betreff: Re: basic dialog nullpointerexception >> >>> On 3/12/07, Veit Guna <[EMAIL PROTECTED]> wrote: >>>> Hi. >>>> >>>> I'm trying to get the basic dialog feature of shale 1.0.4 working. >> I've >>> added the jars view, dialog, basic-dialog, core to my classpath and >> created >>> a dialog xml file in WEB-INF. Now when I try in a h:commandLink an >> action >>> like "dialog:myDialog" a NullPointerException occurs: >>>> java.lang.NullPointerException >>>>at >>>> > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j > ava:97) >>>>at >>>> > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j > ava:87) >>>>at >>>> > org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(Dialo > gNavigationHandler.java:121) >>>>at >>>> > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListen > erImpl.java:84) >>>>at >>>> > org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListe > ner.java:74) >>>>at >>>> ... >>>> >>>> I've taken a look at the BasicDialogManager. It tries to use an >>> uninitialized Map. I guess it should be initialized by the >> BasicLifecycleListener >>> but it isn't. Any hints, what I've forgotten? >>>> Do I have to put the BasicLifecycleListener somewhere manually? >>> In general, you should *not* have to configure this listener manually. >>> It is registered in a listener defined in the >>> shale-dialog-basic-xxx.jar file that you're including. However, not >>> all containers properly implement registering listeners in a TLD >>> inside a JAR file. What container and version are you running on? >>> >>> Craig >>> >>>> Regards, >>>> Veit >>>> >>>> -- >>>> "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... >>>> Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out >>>> >> -- >> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten >> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser >
Re: shale dialog handling
> > But what about the usecase of using other links like a menu? I don't > want to put every outcome on the page to the dialog configuration. > Right now, short of adding all the appropriate transitions to every > view state (yuck), the only mechanism I can think of that might deal > with this is to define your own JSF "default action listener" -- the > > That does indeed seem like a reasonable thing to provide support for > ... gotta think about how for a while, though. Ok, that means there's currently no out-of-the-box shale-dialog function/configuration that can deal with this. So I have to think about it again... > > And what about start-over a dialog when the user clicks a > start-dialog-link again? Is the programmatic approach the only one? > > What does "start over again" really mean? I can think of two > different ways to implement this: For me it simply means, if the user clicks twice (start dialog), handle it like it's the first time the user starts the dialog. So currently that has to be done programmatically, mh. Would be nice if it could be configured :). In practice, isn't this the default dialog usecase? I think in minor cases the developer wants to stop the user from calling the dialog again. The user could step backwards until he reaches the start point, but calling the dialog again would be easier for the user. Both would lead to an initial state (top+stack strategy). > > BTW: a bit off-topic, but what are the major differences between > shale-dialog and spring webflow? > > >From a conceptual level, Shale's dialog manager leverages the fact > >From a functionality point of view, the original intent of Shale Thanks for the detailed answer. I took a look at the current webflow jsf implementation state. It also has some jsf related problems that are open in JIRA... Veit -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
Re: shale dialog handling
Ok, I see that after a dialog has ended, there's no way to get to it again,
using the browser back-button. Clear, that the data object is also lost.
So, lets "forget" about the back-button problem, for now.
But what about the usecase of using other links like a menu? I don't want to
put every outcome on the page to the dialog configuration.
And what about start-over a dialog when the user clicks a start-dialog-link
again? Is the programmatic approach the only one?
What are the best practices with shale-dialog to handle such things?
BTW: a bit off-topic, but what are the major differences between shale-dialog
and spring webflow?
Veit
Original-Nachricht
Datum: Tue, 13 Mar 2007 09:30:42 -0700
Von: "Craig McClanahan" <[EMAIL PROTECTED]>
An: user@shale.apache.org
CC:
Betreff: Re: shale dialog handling
> On 3/13/07, Veit Guna <[EMAIL PROTECTED]> wrote:
> >
> > > The current design assumption is that you can only have one active
> > > dialog per window (or frame), and that you want to control the
> > > lifetime.
> >
> > Hm. Is the lifetime of the dialog not implicitly configured through the
> xml? There's a start point and an end point. That seems sufficient to me to
> specify the lifetime. Since there can be only one active dialog. Although
> it could happen that the user reaches the end page - navigates further and
> then navigates back with the browser buttons to the dialog. What happens
> then? In what situation do I want to programmatically control a _simple_
> dialog? Couldn't that be configured instead?
>
> Because all evidence that the dialog was there is totally gone, the
> dialog will not be automatically reinstated when the back arrow is
> pressed. It is therefore likely that any references your pages have
> to dialog instance specific state information will fail.
>
> You're going to find that nearly every "conversation" or "dialog" type
> framework is going to have some level of problems with back buttons.
> If you can't convince your users that they are operating a web
> *application* and not a web *site*, you're likely to have navigation
> issues.
>
> >
> >
> > > > What comes to my mind is, why doesn't the framework automatically
> stops
> > > > the running dialog and starts it over? What is the best practice
> with
> > > > shale to implement this usecase?
> > >
> > > I suppose it would be possible to implement such a thing. What's not
> > > clear is why you would want to do it. Could you help me understand
> > > your use case a bit?
> >
> > Sure. Think of a webpage, that has a menu on the left. There're entries
> like "Search", "User Profile", "Register" and so on. The user can access
> the menu all the time during navigation in the webapp. Now he clicks on
> "Search" and the dialog starts. He clicks some steps forward in the dialog and
> decides (in the middle of the dialog) to "Register". IllegalStateException
> occurs. Also, when he presses "Search" to start the dialog again, this won't
> be possible. Since he starts the dialog again, why not stop the active
> dialog and start a new one automatically? I could think of a configurable
> dialog attribute in the xml like "autostartover=true" or something.
>
> As above, the dialog manager doesn't deal with back buttons crossing a
> dialog lifetime boundary at all. That's your responsibility if you
> want to do it. Among the problems to consider -- how do you restore
> the state data that was previously there? The dialog manager has no
> clue what kind of thing you stored in the "data" property. Only the
> app can figure that out. Let alone figuring out what state you should
> be returned to ...
>
> >
> > Hm, as I'm writing this, perhaps I misunderstand the dialog component?
> In my point of view, shale should help me to implement pageflows.
> Independent of whether the flow is used in a popupwindow (dialog, no "menu")
> or
> included in a normal navigation case ("main" browser window, with menus etc.).
> Do I understand it correctly?
>
> You do understand correctly what the dialog component is for. What
> you're missing is that it doesn't deal with the "back arrow backing
> into a previously completed dialog" use case, and I don't see any
> general purpose way that this feature could be provided.
>
> >
> >
> > > > Another thing is, clicking other links in the menu when a dialog is
> > > > active. Same here: IllegalStateExcepti
Re: shale dialog handling
> The current design assumption is that you can only have one active
> dialog per window (or frame), and that you want to control the
> lifetime.
Hm. Is the lifetime of the dialog not implicitly configured through the xml?
There's a start point and an end point. That seems sufficient to me to specify
the lifetime. Since there can be only one active dialog. Although it could
happen that the user reaches the end page - navigates further and then
navigates back with the browser buttons to the dialog. What happens then? In
what situation do I want to programmatically control a _simple_ dialog?
Couldn't that be configured instead?
> > What comes to my mind is, why doesn't the framework automatically stops
> > the running dialog and starts it over? What is the best practice with
> > shale to implement this usecase?
>
> I suppose it would be possible to implement such a thing. What's not
> clear is why you would want to do it. Could you help me understand
> your use case a bit?
Sure. Think of a webpage, that has a menu on the left. There're entries like
"Search", "User Profile", "Register" and so on. The user can access the menu
all the time during navigation in the webapp. Now he clicks on "Search" and the
dialog starts. He clicks some steps forward in the dialog and decides (in the
middle of the dialog) to "Register". IllegalStateException occurs. Also, when
he presses "Search" to start the dialog again, this won't be possible. Since he
starts the dialog again, why not stop the active dialog and start a new one
automatically? I could think of a configurable dialog attribute in the xml like
"autostartover=true" or something.
Hm, as I'm writing this, perhaps I misunderstand the dialog component? In my
point of view, shale should help me to implement pageflows. Independent of
whether the flow is used in a popupwindow (dialog, no "menu") or included in a
normal navigation case ("main" browser window, with menus etc.). Do I
understand it correctly?
> > Another thing is, clicking other links in the menu when a dialog is
> > active. Same here: IllegalStateException. A user doesn't care about
> > program-friendly navigation. A user want's to navigate everywhere he
> > likes to.
> For dealing with the back and forward buttons, check out the context
> init parameter "org.apache.shale.dialog.basic.STRATEGY" if you are
> using the basic implementation. You can control whether and how state
> information is synchronized as the user moves forwards or backwards
> through the dialog.
Yes I know. This is very useful because with top or stack the dialog data will
automatically be set to a consistent (to the current dialog page) state.
> For dealing with navigation from inside the dialog to somewhere
> outside, the thing to remember is that the dialog manager takes over
> normal navigation processing when a dialog is active. Therefore, it
> is up to you to provide transitions for *all* possible outcomes that
> might be returned from the current page. You don't have to change the
That might be :). But in which real life webapp there is ONLY a dialog active
and no menus, etc.? If we talk only about modal popup windows, that might be
true, but in all other cases the dialog is embedded in a bunch of other links
around. I really don't want to put ALL the links/outcomes around the dialog
(menu etc.) in the dialog definition :)!
So, If the shale dialog component is only designed for modal popups, all makes
sense and you can forget everything I wrote above.
Veit
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out
shale dialog handling
Hi. I'm new to the shale dialog component and I'm evaluating whether to use it in my webapp. Since documentation is a bit poor, I hope somebody can clear things up for me. First thing I encountered was, that a dialog can't be started "twice". I have a menu where for example a search dialog can be started through a commandLink action="dialog:foobar". If I press the search link again, a IllegalStateException occurs. I've read something on the mailing list about stopping the dialog before starting it again. But that sounds odd to me. Why doesn't the framework do this for me :)? If I would stop/start it manually, where would I do it? Since the commandLink instantly calls the dialog with action="dialog:foobar", I have to add an additional method to start the dialog programmatically. But for what is the action="dialog:foobar" then if it breaks if someone calls it twice? What comes to my mind is, why doesn't the framework automatically stops the running dialog and starts it over? What is the best practice with shale to implement this usecase? Another thing is, clicking other links in the menu when a dialog is active. Same here: IllegalStateException. A user doesn't care about program-friendly navigation. A user want's to navigate everywhere he likes to. How is this handled with shale? Is there any documentation about this problems/solutions? Thanks in advance. Veit
SV: Re: basic dialog nullpointerexception
Hi again. I upgraded my Tomcat 5.5.17 installation (it wasn't 5.5.16) to tomcat 5.5.23 and now the BasicLifecycleListener gets invoked. Seemed to be a problem with tomcat?! Regards, Veit Original-Nachricht Datum: Mon, 12 Mar 2007 13:41:26 +0100 Von: "Veit Guna" <[EMAIL PROTECTED]> An: user@shale.apache.org CC: Betreff: Re: basic dialog nullpointerexception > I'm using tomcat 5.5.16. > > > Original-Nachricht > Datum: Mon, 12 Mar 2007 05:31:50 -0700 > Von: "Craig McClanahan" <[EMAIL PROTECTED]> > An: user@shale.apache.org > CC: > Betreff: Re: basic dialog nullpointerexception > > > On 3/12/07, Veit Guna <[EMAIL PROTECTED]> wrote: > > > Hi. > > > > > > I'm trying to get the basic dialog feature of shale 1.0.4 working. > I've > > added the jars view, dialog, basic-dialog, core to my classpath and > created > > a dialog xml file in WEB-INF. Now when I try in a h:commandLink an > action > > like "dialog:myDialog" a NullPointerException occurs: > > > > > > java.lang.NullPointerException > > >at > > > > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:97) > > >at > > > > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:87) > > >at > > > > > > org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:121) > > >at > > > > > > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84) > > >at > > > > > > org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74) > > >at > > > ... > > > > > > I've taken a look at the BasicDialogManager. It tries to use an > > uninitialized Map. I guess it should be initialized by the > BasicLifecycleListener > > but it isn't. Any hints, what I've forgotten? > > > > > > Do I have to put the BasicLifecycleListener somewhere manually? > > > > In general, you should *not* have to configure this listener manually. > > It is registered in a listener defined in the > > shale-dialog-basic-xxx.jar file that you're including. However, not > > all containers properly implement registering listeners in a TLD > > inside a JAR file. What container and version are you running on? > > > > Craig > > > > > > > > Regards, > > > Veit > > > > > > -- > > > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > > > Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out > > > > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
Re: basic dialog nullpointerexception
I'm using tomcat 5.5.16. Original-Nachricht Datum: Mon, 12 Mar 2007 05:31:50 -0700 Von: "Craig McClanahan" <[EMAIL PROTECTED]> An: user@shale.apache.org CC: Betreff: Re: basic dialog nullpointerexception > On 3/12/07, Veit Guna <[EMAIL PROTECTED]> wrote: > > Hi. > > > > I'm trying to get the basic dialog feature of shale 1.0.4 working. I've > added the jars view, dialog, basic-dialog, core to my classpath and created > a dialog xml file in WEB-INF. Now when I try in a h:commandLink an action > like "dialog:myDialog" a NullPointerException occurs: > > > > java.lang.NullPointerException > >at > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:97) > >at > > > org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:87) > >at > > > org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:121) > >at > > > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84) > >at > > > org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74) > >at > > ... > > > > I've taken a look at the BasicDialogManager. It tries to use an > uninitialized Map. I guess it should be initialized by the > BasicLifecycleListener > but it isn't. Any hints, what I've forgotten? > > > > Do I have to put the BasicLifecycleListener somewhere manually? > > In general, you should *not* have to configure this listener manually. > It is registered in a listener defined in the > shale-dialog-basic-xxx.jar file that you're including. However, not > all containers properly implement registering listeners in a TLD > inside a JAR file. What container and version are you running on? > > Craig > > > > > Regards, > > Veit > > > > -- > > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > > Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out > > -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
basic dialog nullpointerexception
Hi. I'm trying to get the basic dialog feature of shale 1.0.4 working. I've added the jars view, dialog, basic-dialog, core to my classpath and created a dialog xml file in WEB-INF. Now when I try in a h:commandLink an action like "dialog:myDialog" a NullPointerException occurs: java.lang.NullPointerException at org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:97) at org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.java:87) at org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:121) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84) at org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74) at ... I've taken a look at the BasicDialogManager. It tries to use an uninitialized Map. I guess it should be initialized by the BasicLifecycleListener but it isn't. Any hints, what I've forgotten? Do I have to put the BasicLifecycleListener somewhere manually? Regards, Veit -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
Re: My exception handling is broken
Hi. I encountered the same problem. I started development with shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too. That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example acegi exceptions didn't get propagated anymore to its ExceptionFilter. At this time I thought, it worked before because of a bug in the SNAPSHOT release and that got fixed in the final 1.0.4. Something changed in the way of handling exceptions I guess. I can't remember exactly what I changed to get it running in 1.0.4 again, but it had something todo with trowing exceptions. In the past, I think the Shale Controller threw exceptions that were queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this isn't done anymore. I had to throw the exception explicitly in my shale exception handler to get it propagated. I would be also interested in what changed exactly and what's the right way to handle exceptions in shale... regards, Veit Ingo Düppe schrieb: > Hi, > > I guess I missed some changes in shale 1.0.4. I override the > DefaultExceptionHandling so that my backing bean can throw to types of > exceptions one of my ApplicationExceptions and the unchecked > SystemExceptions. These two types were handled by the > DefaultExceptionHandler. For instance, the application exception just > ends up in an error message on the same view. > > But now there is a responseComplete within the ShaleViewRoot (Is this > class new?) that prevents the rendering after exception handling. > > So, do I need to introduce my own ViewRoot component or what is the > recommended way to handle my exceptions? > > Regards > Ingo > >
Re: Shale's commonsValidator + Facelets
So, I got it now working so far.
The missing JS msgbox was a JS-error problem. In my resource bundle I
used quotes around the fieldname and they won't be escaped so this broke
the JS. Using " or " didn't work either because it won't be
translated in the msgbox :(. So ' and " aren't an option. Not so nice
that it can't handle the encoding properly.
Another thing is, that the JS doesn't check the required flag on
selectboxes. So this will only be handled on server-side validation -
also not so nice presenting the user two different error msg "styles".
So, after I've got it "working" I must admit that this won't be an
option for me anymore. All the points are no go's for me.
Perhaps I will take a look at:
http://jsf-comp.sourceforge.net/components/clientvalidators/index.html
or
http://wiki.apache.org/myfaces/OptionalValidationFramework
which seem to be more integrated into jsf. But I will have separate
view/business logic validations then :(.
Thanks so far.
regards,
Veit
Veit Guna schrieb:
> David Geary schrieb:
>> 2006/11/25, Veit Guna <[EMAIL PROTECTED]>:
>>> Now the validation takes place and the JS gets rendered into the page.
>>> Something with the validation msg looks strange,
>>
>> What does it look like?
>
> The problem was, that I put a EL resource-bundle reference to the arg
> parameter of the commonsValidator that pointed to the error msg key in
> my resource bundle. I thought this parameter is used for the error msg -
> so it can be customized. So the raw msg of my RB was inserted in the
> default shale error msg as {0} - that looked strange ;). Didn't find
> documentation about that.
>
> BTW: why do I have to pass the label explicit by the arg parameter to
> the validator? The information is already in the component tree. It
> could take it from there?! If I leave it out, (null) is shown for the
> label in the error msg. Another strange things is, I mixed on a form
> commonsValidator with std. JSF validators. Now the problem arises, that
> shale allows only ONE error msg. Not separate summary and detail msgs as
> JSF offers. Now when the form gets validated I get in h:messages the
> summary plus the detail for jsf validators and from the commonsValidator
> just ONE msg. That looks odd. So there is the same msg for h:message and
> h:messages when using commonsValidator. Could that be optimized?
>
>
>> but I'll figure that
>>> out. Also I expected a msgbox to appear due to JS client verification?!
>> Yes. If you specify client="true", you should see a JS alert if you have JS
>> turned on; otherwise, the validation will be performed on the server.
>
> Thats the second strange thing. As I mentioned before I mix both
> validators - jsf and commmonsValidator. I've set client and server to
> true. But there's no JS msgbox concerning the required field when
> sending it. There's just a "normal" msg, like for the other jsf
> validators. I got _once_ a msgbox - I don't know why. But then even the
> msg was not I18N style - the german umlaut got rendered as some html
> encoding - can't remember exactly. Is there a problem mixing both
> validation methods in one form? I expected JS validation first with a
> msgbox, after that the server validation of the other jsf validator fields.
>
> Any hints?
>
> regards,
> Veit
>
Re: Shale's commonsValidator + Facelets
David Geary schrieb:
> 2006/11/25, Veit Guna <[EMAIL PROTECTED]>:
>>
>> Now the validation takes place and the JS gets rendered into the page.
>> Something with the validation msg looks strange,
>
>
> What does it look like?
The problem was, that I put a EL resource-bundle reference to the arg
parameter of the commonsValidator that pointed to the error msg key in
my resource bundle. I thought this parameter is used for the error msg -
so it can be customized. So the raw msg of my RB was inserted in the
default shale error msg as {0} - that looked strange ;). Didn't find
documentation about that.
BTW: why do I have to pass the label explicit by the arg parameter to
the validator? The information is already in the component tree. It
could take it from there?! If I leave it out, (null) is shown for the
label in the error msg. Another strange things is, I mixed on a form
commonsValidator with std. JSF validators. Now the problem arises, that
shale allows only ONE error msg. Not separate summary and detail msgs as
JSF offers. Now when the form gets validated I get in h:messages the
summary plus the detail for jsf validators and from the commonsValidator
just ONE msg. That looks odd. So there is the same msg for h:message and
h:messages when using commonsValidator. Could that be optimized?
> but I'll figure that
>> out. Also I expected a msgbox to appear due to JS client verification?!
>
> Yes. If you specify client="true", you should see a JS alert if you have JS
> turned on; otherwise, the validation will be performed on the server.
Thats the second strange thing. As I mentioned before I mix both
validators - jsf and commmonsValidator. I've set client and server to
true. But there's no JS msgbox concerning the required field when
sending it. There's just a "normal" msg, like for the other jsf
validators. I got _once_ a msgbox - I don't know why. But then even the
msg was not I18N style - the german umlaut got rendered as some html
encoding - can't remember exactly. Is there a problem mixing both
validation methods in one form? I expected JS validation first with a
msgbox, after that the server validation of the other jsf validator fields.
Any hints?
regards,
Veit
Re: Shale's commonsValidator + Facelets
I don't need the ValidatorVar (yet?). I've found your post: http://www.mail-archive.com/user@shale.apache.org/msg00631.html and this: http://www.mail-archive.com/user@shale.apache.org/msg00547.html That lead me to: javax.faces.FacesException: Undefined component type org.apache.shale.component.ValidatorScript Corrected the shale taglib component-type: org.apache.shale.component.ValidatorScript to org.apache.shale.ValidatorScript Now the validation takes place and the JS gets rendered into the page. Something with the validation msg looks strange, but I'll figure that out. Also I expected a msgbox to appear due to JS client verification?! regards, Veit Wendy Smoak schrieb: > On 11/25/06, Veit Guna <[EMAIL PROTECTED]> wrote: > >> I'm also trying to get apache commons validator running together with >> shale-1.0.4-SNAPSHOT and facelets 1.11. This is because I can use the >> commons-validator package for business validation, too - independent of >> the view technologie. > ... >> Any hints what the problem might be? Perhaps one need really a Facelet >> Tag handler to get it running? > > That's what I'm told, but I didn't get very far, either: > > http://www.nabble.com/Help-with-a-TagHandler-for-Shale%27s-%27validatorVar%27-t2398508.html > >
Shale's commonsValidator + Facelets
Hi. I'm also trying to get apache commons validator running together with shale-1.0.4-SNAPSHOT and facelets 1.11. This is because I can use the commons-validator package for business validation, too - independent of the view technologie. I've read the posts on the mailing-list but now I'm stuck somehow. The following things I've done: - added shale-core, shale-validator and shale-view to my libs - added the things I need to a facelets taglib.xml like in the posts I've seen so far and added a reference to it in the web.xml: http://shale.apache.org/core token org.apache.shale.Token org.apache.shale.Token commonsValidator org.apache.shale.CommonsValidator - referenced the commonsValidator as follows in the xhtml file: - Added the shale namespace to the top of the page: xmlns:sh="http://shale.apache.org/core"; So, I'm also using the token tag - that works fine. That means shale works as expected. But somehow the commonsValidator doesn't seem to work. When I submit the page, no validation takes place. If I changed the name of the commonsValidator tag to something else, I get an error that this tag doesn't exist. So that is setup correctly so far. Any hints what the problem might be? Perhaps one need really a Facelet Tag handler to get it running? btw: people.apache.org is up and running again. regards, Veit
shale download
Hi. Seems that the shale download site (people.apache.org) is down. Is there an alternative where I can get for example pre-build shale-validator 1.0.4-SNAPSHOTS? regards, Veit
