You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Craig McClanahan <cr...@gmail.com> on 2005/01/04 05:50:12 UTC
"Use Cases" Example Webapp for the Shale proposal
(Cross posting because this topic has come up on all of the lists in
the last couple weeks.)
I just committed into the Struts SVN repository a new example
application (struts-shale-usecases) that illustrate's the different
take that Shale has on how an application framework can be built
around JSF, including support for "dialog scope" (longer than a
request, but shorter than a session). I've updated the Shale wiki
page to contain pointers to the latest API documentation for both
Shale and the example app:
http://wiki.apache.org/struts/StrutsShale
and nightly builds of the example app will be available starting
tonight (pointer is on the Wiki page above).
The commit message was over the max size allowed, so here's the
descriptive text:
------------------------------------------------------------------------------------------------------------
Initial commit of an example application for Shale, illustrating more
interesting features than one sees with MailReader. In particular:
* Use of application level "controller" features to filter out
direct requests for JSP and JSPF (JSP fragment) resources, since
they should only be accessed via *.faces URLs.
See "src/web/WEB-INF/chain-config.xml" for configuration of
this application's additions to the standard Shale processing chain.
* Use of DialogController for a sophisticated workflow with multiple
entries and exits: logon dialog for a portal-type site that supports
creating new profiles (with or without an email confirmation), plus
"remember me" cookies.
See the javadocs for package "org.apache.shale.usecases.logon" for
an overview of this functionality, plus an activity diagram describing
the state transitions. (The diagram was produced with Poseidon for UML
Community Edition, version 3.0, and the Poseidon project file is
also checked in).
* Use of standard JSF facilities to support a language picker, based on
the supported locales for the application. (NOTE - at present switching
languages does not appear to do anything, but that is because I only
checked in the default (English) properties file -- if someone would
like to translate "src/java/org/apache/shale/usecases/view/Bundle.properties"
into other languages, I'd be happy to check it in.
See "src/web/locale/select.jsp" for the JSP page that does this,
and "src/java/org/apache/shale/usecases/locale/Select.java" for
the corresponding backing bean.
* Use of <managed-property> elements to configure the properties of a
newly created managed bean, using either literal values or expressions
(essentially an example of IoC with setter injection).
In this example, such properties are used to:
- Configure the DAO object that is used by the business logic of
the application, using
- Configure the functionality of the DialogController instance,
describing whether email confirmations and remember me cookies
should be enabled or not.
See "src/web/WEB-INF/faces-config.xml" for configuration of this feature.
* General purpose "domains" object (cached in application scope the first
time it is accessed) to provide localized lists of SelectItem value/label
pairs (these provide the content for dropdown lists etc.).
See "src/java/org/apache/shale/usecases/util/Domains.java"
The Javadocs for this application will be published soon, with a pointer on
the Wiki, and nightly builds will commence this evening.
------------------------------------------------------------------------------------------------------------
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Sean Schofield <se...@gmail.com>.
> Even if that happens, there will clearly be a transition period for
> existing applications. And I will be happy to support transition
> users, with the Struts-Faces Integration Library. But, from what I
> have seen in the market, Struts is becoming increasingly less relevant
> for new application development. JSF is only going to accelerate that
> trend -- but it was there already. Anyone who ignores what is
> happening already is acting like an ostrich.
I think this will take some time but I agree that it will happen. Not
everyone will embrace the change right away (or ever) but that is for
each developer to decide.
Craig's postings (and the resulting debates) have helped me to realize
just how mature of a technology Struts is becoming. "Mature" doesn't
mean useless but it does mean not much room to grow. Craig's ideas
might be a little ahead of the game for some of us, but we shouldn't
be discouraging attempts to think beyond what we are comfortable with.
Keep up the innovation. I would try and contribute more but right now
I am having trouble keeping up with you!
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 3 Jan 2005 22:46:03 -0800, Dakota Jack <da...@gmail.com> wrote:
> ????
>
> Whatever happened to the proposals to move this JSF implementation to
> MyFaces? That would seem to be much more appropriate. Perhaps it
> could be called JSFShale or FacesShale? What this has to do at all
> with Struts has never, in my opinion, been explained, beyond the
> desire to appropriate the Struts name.
>
As has become depressingly common, you have the most important
question totally backwards.
JSF will succeed or fail on its own merits. Struts is irrelevant to
that, other than the fact that we can provide a path to use ~10% of
JSF's capabilities (you can use JSF components but not the rest of the
capabilities of JSF via the integration library).
Struts, on the other hand, is already (without taking JSF into
consideration) a long ways behind the state of the art. With the
advent of JSF, it borders on becoming (over time) irrelevant for new
application development. Of course that is not an instantanous
process, but you can't stop fundamental shifts in direction, either.
And none of the proposed 1.3.x changes make the slightest bit of
difference in this regard.
What is it going to say to the world if the person who *developed*
Struts in the first place says it is no longer the best solution?
That appears to be a foregone conclusion if the Struts development
community agrees with your position. (This is *not* my preference,
which is why I'm still pushing Shale to be Struts 2.x -- but let's be
clear; this is a "put up or shut up" sort of decision.)
Even if that happens, there will clearly be a transition period for
existing applications. And I will be happy to support transition
users, with the Struts-Faces Integration Library. But, from what I
have seen in the market, Struts is becoming increasingly less relevant
for new application development. JSF is only going to accelerate that
trend -- but it was there already. Anyone who ignores what is
happening already is acting like an ostrich.
That's not something I plan to do. If the Struts community doesn't
support something like Shale, I'm *personally* going to compete with
it for new development. That doesn't seem like a "good thing", but
sometimes that sort of thing happens.
> Jack
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: "Use Cases" Example Webapp for the Shale proposal
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Jack,
it is nice that you like to enlarge MyFaces :-)
But I think it's good to see Shale as a framework
for JSF, like Struts is a framework for Servlet/JSP (aka Model2).
So would it be good to host Struts @ Tomcat folks? Only why
it is a *servlet-framework* ?
Something like Struts is beyond the scope of Servlet-Spec.
The same with Shale. Shale isn't a implementation of
JSF spec. It is a framework on top of the spec.
Regards,
Matthias
> -----Original Message-----
> From: Dakota Jack [mailto:dakota.jack@gmail.com]
> Sent: Tuesday, January 04, 2005 7:46 AM
> To: Struts Developers List; craigmcc@apache.org
> Subject: Re: "Use Cases" Example Webapp for the Shale proposal
>
>
> ????
>
> Whatever happened to the proposals to move this JSF
> implementation to MyFaces? That would seem to be much more
> appropriate. Perhaps it could be called JSFShale or
> FacesShale? What this has to do at all with Struts has
> never, in my opinion, been explained, beyond the desire to
> appropriate the Struts name.
>
> Jack
>
>
> On Mon, 3 Jan 2005 20:50:12 -0800, Craig McClanahan
> <cr...@gmail.com> wrote:
> > (Cross posting because this topic has come up on all of the
> lists in
> > the last couple weeks.)
> >
> > I just committed into the Struts SVN repository a new example
> > application (struts-shale-usecases) that illustrate's the different
> > take that Shale has on how an application framework can be built
> > around JSF, including support for "dialog scope" (longer than a
> > request, but shorter than a session). I've updated the Shale wiki
> > page to contain pointers to the latest API documentation for both
> > Shale and the example app:
> >
> > http://wiki.apache.org/struts/StrutsShale
> >
> > and nightly builds of the example app will be available starting
> > tonight (pointer is on the Wiki page above).
> >
> > The commit message was over the max size allowed, so here's the
> > descriptive text:
> >
> ----------------------------------------------------------------------
> > --------------------------------------
> >
> > Initial commit of an example application for Shale,
> illustrating more
> > interesting features than one sees with MailReader. In particular:
> >
> > * Use of application level "controller" features to filter out
> > direct requests for JSP and JSPF (JSP fragment) resources, since
> > they should only be accessed via *.faces URLs.
> >
> > See "src/web/WEB-INF/chain-config.xml" for configuration of
> > this application's additions to the standard Shale
> processing chain.
> >
> > * Use of DialogController for a sophisticated workflow with multiple
> > entries and exits: logon dialog for a portal-type site
> that supports
> > creating new profiles (with or without an email
> confirmation), plus
> > "remember me" cookies.
> >
> > See the javadocs for package "org.apache.shale.usecases.logon" for
> > an overview of this functionality, plus an activity
> diagram describing
> > the state transitions. (The diagram was produced with
> Poseidon for UML
> > Community Edition, version 3.0, and the Poseidon project file is
> > also checked in).
> >
> > * Use of standard JSF facilities to support a language
> picker, based on
> > the supported locales for the application. (NOTE - at
> present switching
> > languages does not appear to do anything, but that is
> because I only
> > checked in the default (English) properties file -- if
> someone would
> > like to translate
> "src/java/org/apache/shale/usecases/view/Bundle.properties"
> > into other languages, I'd be happy to check it in.
> >
> > See "src/web/locale/select.jsp" for the JSP page that does this,
> > and "src/java/org/apache/shale/usecases/locale/Select.java" for
> > the corresponding backing bean.
> >
> > * Use of <managed-property> elements to configure the
> properties of a
> > newly created managed bean, using either literal values
> or expressions
> > (essentially an example of IoC with setter injection).
> > In this example, such properties are used to:
> > - Configure the DAO object that is used by the business logic of
> > the application, using
> > - Configure the functionality of the DialogController instance,
> > describing whether email confirmations and remember me cookies
> > should be enabled or not.
> >
> > See "src/web/WEB-INF/faces-config.xml" for configuration of this
> > feature.
> >
> > * General purpose "domains" object (cached in application
> scope the first
> > time it is accessed) to provide localized lists of
> SelectItem value/label
> > pairs (these provide the content for dropdown lists etc.).
> >
> > See "src/java/org/apache/shale/usecases/util/Domains.java"
> >
> > The Javadocs for this application will be published soon, with a
> > pointer on the Wiki, and nightly builds will commence this evening.
> >
> >
> ----------------------------------------------------------------------
> > --------------------------------------
> >
> > Craig
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> ------------------------------
>
> "You can lead a horse to water but you cannot make it float
> on its back."
>
> ~Dakota Jack~
>
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for
> eagles to be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
> -----------------------------------------------
>
> "This message may contain confidential and/or privileged
> information. If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy,
> disclose, or take any action based on this message or any
> information herein. If you have received this message in
> error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Dakota Jack <da...@gmail.com>.
????
Whatever happened to the proposals to move this JSF implementation to
MyFaces? That would seem to be much more appropriate. Perhaps it
could be called JSFShale or FacesShale? What this has to do at all
with Struts has never, in my opinion, been explained, beyond the
desire to appropriate the Struts name.
Jack
On Mon, 3 Jan 2005 20:50:12 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> (Cross posting because this topic has come up on all of the lists in
> the last couple weeks.)
>
> I just committed into the Struts SVN repository a new example
> application (struts-shale-usecases) that illustrate's the different
> take that Shale has on how an application framework can be built
> around JSF, including support for "dialog scope" (longer than a
> request, but shorter than a session). I've updated the Shale wiki
> page to contain pointers to the latest API documentation for both
> Shale and the example app:
>
> http://wiki.apache.org/struts/StrutsShale
>
> and nightly builds of the example app will be available starting
> tonight (pointer is on the Wiki page above).
>
> The commit message was over the max size allowed, so here's the
> descriptive text:
> ------------------------------------------------------------------------------------------------------------
>
> Initial commit of an example application for Shale, illustrating more
> interesting features than one sees with MailReader. In particular:
>
> * Use of application level "controller" features to filter out
> direct requests for JSP and JSPF (JSP fragment) resources, since
> they should only be accessed via *.faces URLs.
>
> See "src/web/WEB-INF/chain-config.xml" for configuration of
> this application's additions to the standard Shale processing chain.
>
> * Use of DialogController for a sophisticated workflow with multiple
> entries and exits: logon dialog for a portal-type site that supports
> creating new profiles (with or without an email confirmation), plus
> "remember me" cookies.
>
> See the javadocs for package "org.apache.shale.usecases.logon" for
> an overview of this functionality, plus an activity diagram describing
> the state transitions. (The diagram was produced with Poseidon for UML
> Community Edition, version 3.0, and the Poseidon project file is
> also checked in).
>
> * Use of standard JSF facilities to support a language picker, based on
> the supported locales for the application. (NOTE - at present switching
> languages does not appear to do anything, but that is because I only
> checked in the default (English) properties file -- if someone would
> like to translate "src/java/org/apache/shale/usecases/view/Bundle.properties"
> into other languages, I'd be happy to check it in.
>
> See "src/web/locale/select.jsp" for the JSP page that does this,
> and "src/java/org/apache/shale/usecases/locale/Select.java" for
> the corresponding backing bean.
>
> * Use of <managed-property> elements to configure the properties of a
> newly created managed bean, using either literal values or expressions
> (essentially an example of IoC with setter injection).
> In this example, such properties are used to:
> - Configure the DAO object that is used by the business logic of
> the application, using
> - Configure the functionality of the DialogController instance,
> describing whether email confirmations and remember me cookies
> should be enabled or not.
>
> See "src/web/WEB-INF/faces-config.xml" for configuration of this feature.
>
> * General purpose "domains" object (cached in application scope the first
> time it is accessed) to provide localized lists of SelectItem value/label
> pairs (these provide the content for dropdown lists etc.).
>
> See "src/java/org/apache/shale/usecases/util/Domains.java"
>
> The Javadocs for this application will be published soon, with a pointer on
> the Wiki, and nightly builds will commence this evening.
>
> ------------------------------------------------------------------------------------------------------------
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
Hello Craig:
Thanks for the insight. I have been working with Struts since your
beginning in the 2nd half of 2000. I aggree with your technology
assessment and just concentrate on getting the job done.
BaTien
DBGROUPS
Craig McClanahan wrote:
>On Tue, 04 Jan 2005 09:48:32 -0700, BaTien Duong
><ba...@dbgroups.com> wrote:
>
>
>>Hello Craig:
>>
>>Good work. Thanks for your effort. We always wish to have more than 24
>>hours a day. I wish to have some spare time to get back to this.
>>
>>One quick question about the framework: What is the appropriate tool to
>>use for configuration in different tiers? I thought Jsf is appropriate
>>in the presentation tier. The business tier and integration tier can
>>live in different servers separate from the server of the presentation
>>tier. (I currently use Spring IoC for the configuration of these tiers).
>>>From a glance at your javadoc, you make Jsf as *the* configuration tool
>>for DAO layer. Should it be appropriate to use chain of request/response
>>framework to connect the tiers?
>>
>>
>
>As with the original design of Struts, I tried not to impose these
>decisions on the application developer -- you can choose your favorite
>techniques. However, it's instructive to note that, for its own
>purposes, this particular example app uses the IoC-ish configuration
>support that JSF already provides (via managed beans) to wire together
>the business logic and DAO instances.
>
>If the logic were any more complicated than the current example (and
>other use cases certainly will be), using a chain to assemble your
>tier-crossing (or even the processing within a tier) seems to make a
>lot of sense.
>
>
>
>>Thanks
>>
>>BaTien
>>DBGROUPS
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 04 Jan 2005 09:48:32 -0700, BaTien Duong
<ba...@dbgroups.com> wrote:
> Hello Craig:
>
> Good work. Thanks for your effort. We always wish to have more than 24
> hours a day. I wish to have some spare time to get back to this.
>
> One quick question about the framework: What is the appropriate tool to
> use for configuration in different tiers? I thought Jsf is appropriate
> in the presentation tier. The business tier and integration tier can
> live in different servers separate from the server of the presentation
> tier. (I currently use Spring IoC for the configuration of these tiers).
> From a glance at your javadoc, you make Jsf as *the* configuration tool
> for DAO layer. Should it be appropriate to use chain of request/response
> framework to connect the tiers?
As with the original design of Struts, I tried not to impose these
decisions on the application developer -- you can choose your favorite
techniques. However, it's instructive to note that, for its own
purposes, this particular example app uses the IoC-ish configuration
support that JSF already provides (via managed beans) to wire together
the business logic and DAO instances.
If the logic were any more complicated than the current example (and
other use cases certainly will be), using a chain to assemble your
tier-crossing (or even the processing within a tier) seems to make a
lot of sense.
>
> Thanks
>
> BaTien
> DBGROUPS
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
Hello Craig:
Good work. Thanks for your effort. We always wish to have more than 24
hours a day. I wish to have some spare time to get back to this.
One quick question about the framework: What is the appropriate tool to
use for configuration in different tiers? I thought Jsf is appropriate
in the presentation tier. The business tier and integration tier can
live in different servers separate from the server of the presentation
tier. (I currently use Spring IoC for the configuration of these tiers).
>From a glance at your javadoc, you make Jsf as *the* configuration tool
for DAO layer. Should it be appropriate to use chain of request/response
framework to connect the tiers?
Thanks
BaTien
DBGROUPS
Craig McClanahan wrote:
>(Cross posting because this topic has come up on all of the lists in
>the last couple weeks.)
>
>I just committed into the Struts SVN repository a new example
>application (struts-shale-usecases) that illustrate's the different
>take that Shale has on how an application framework can be built
>around JSF, including support for "dialog scope" (longer than a
>request, but shorter than a session). I've updated the Shale wiki
>page to contain pointers to the latest API documentation for both
>Shale and the example app:
>
> http://wiki.apache.org/struts/StrutsShale
>
>and nightly builds of the example app will be available starting
>tonight (pointer is on the Wiki page above).
>
>The commit message was over the max size allowed, so here's the
>descriptive text:
>------------------------------------------------------------------------------------------------------------
>
>Initial commit of an example application for Shale, illustrating more
>interesting features than one sees with MailReader. In particular:
>
>* Use of application level "controller" features to filter out
> direct requests for JSP and JSPF (JSP fragment) resources, since
> they should only be accessed via *.faces URLs.
>
> See "src/web/WEB-INF/chain-config.xml" for configuration of
> this application's additions to the standard Shale processing chain.
>
>* Use of DialogController for a sophisticated workflow with multiple
> entries and exits: logon dialog for a portal-type site that supports
> creating new profiles (with or without an email confirmation), plus
> "remember me" cookies.
>
> See the javadocs for package "org.apache.shale.usecases.logon" for
> an overview of this functionality, plus an activity diagram describing
> the state transitions. (The diagram was produced with Poseidon for UML
> Community Edition, version 3.0, and the Poseidon project file is
> also checked in).
>
>* Use of standard JSF facilities to support a language picker, based on
> the supported locales for the application. (NOTE - at present switching
> languages does not appear to do anything, but that is because I only
> checked in the default (English) properties file -- if someone would
> like to translate "src/java/org/apache/shale/usecases/view/Bundle.properties"
> into other languages, I'd be happy to check it in.
>
> See "src/web/locale/select.jsp" for the JSP page that does this,
> and "src/java/org/apache/shale/usecases/locale/Select.java" for
> the corresponding backing bean.
>
>* Use of <managed-property> elements to configure the properties of a
> newly created managed bean, using either literal values or expressions
> (essentially an example of IoC with setter injection).
> In this example, such properties are used to:
> - Configure the DAO object that is used by the business logic of
> the application, using
> - Configure the functionality of the DialogController instance,
> describing whether email confirmations and remember me cookies
> should be enabled or not.
>
> See "src/web/WEB-INF/faces-config.xml" for configuration of this feature.
>
>* General purpose "domains" object (cached in application scope the first
> time it is accessed) to provide localized lists of SelectItem value/label
> pairs (these provide the content for dropdown lists etc.).
>
> See "src/java/org/apache/shale/usecases/util/Domains.java"
>
>The Javadocs for this application will be published soon, with a pointer on
>the Wiki, and nightly builds will commence this evening.
>
>------------------------------------------------------------------------------------------------------------
>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Sean Schofield <se...@gmail.com>.
> In addition, the Tiles support is unlikely to work optimally until
> Shale addes support for ViewControllers on a Tile (or, more generally,
> on a JSF subview) -- a feature that is on my TODO list.
Oh yeah!
> Craig
sean
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by BaTien Duong <du...@gmail.com>.
Craig McClanahan wrote:
>Note that Shale also includes its own ViewHandler extension, so this
>would be unlikely to work unless the MyFaces one delegates its
>createView() and restoreView() calls to the Shale version.
>
>In addition, the Tiles support is unlikely to work optimally until
>Shale addes support for ViewControllers on a Tile (or, more generally,
>on a JSF subview) -- a feature that is on my TODO list.
>
>Craig
>
>
>
Is that what we all want to hear to meet Craig standard? This is back to
my tiles question at the beginning of Shale. My sense is right on the
target :-)
BaTien
DBGROUPS
>On Wed, 05 Jan 2005 08:59:49 -0700, BaTien Duong <du...@gmail.com> wrote:
>
>
>>Matthias Wessendorf wrote:
>>
>>
>>
>>>I just tried the nightly build and it works fine
>>>with MyFaces.
>>>
>>>What must be done to run this app with MyFaces?
>>>
>>>a) remove jsf files from RI
>>>b) add jar files from MyFaces example
>>> (not only myfaces.jar also others like commons-fileupload.jar)
>>>c) add MyFaces listener to web.xml
>>> (and rename net.sf -> org.apache)
>>>
>>>I also removed the work directory inside of my tomcat.
>>>
>>>Done!
>>>
>>>so now it is time to dig inside the sources
>>>for this app and Shale ;-)
>>>
>>>Cheers!
>>>Matthias
>>>
>>>
>>>
>>>
>>>
>>Matthias:
>>
>>Wow ;-) we are in an exiting time. Please try to see if the
>>JspTilesViewHandlerImpl work properly with Shale as an application
>>controller. I have not tried this but it is very important to know,
>>especially for those who work with myfaces.
>>
>>Thanks
>>
>>BaTien
>>DBGROUPS
>>
>>
>>
>>>>-----Original Message-----
>>>>Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEM
>>>>Sent: Tuesday, January 04, 2005 5:50 AM
>>>>To: Struts Developers List; MyFaces Development
>>>>Cc: MyFaces Discussion
>>>>Subject: "Use Cases" Example Webapp for the Shale proposal
>>>>
>>>>
>>>>(Cross posting because this topic has come up on all of the
>>>>lists in the last couple weeks.)
>>>>
>>>>I just committed into the Struts SVN repository a new example
>>>>application (struts-shale-usecases) that illustrate's the
>>>>different take that Shale has on how an application framework
>>>>can be built around JSF, including support for "dialog scope"
>>>>(longer than a request, but shorter than a session). I've
>>>>updated the Shale wiki page to contain pointers to the latest
>>>>API documentation for both Shale and the example app:
>>>>
>>>> http://wiki.apache.org/struts/StrutsShale
>>>>
>>>>and nightly builds of the example app will be available
>>>>starting tonight (pointer is on the Wiki page above).
>>>>
>>>>The commit message was over the max size allowed, so here's
>>>>the descriptive text:
>>>>--------------------------------------------------------------
>>>>----------------------------------------------
>>>>
>>>>Initial commit of an example application for Shale,
>>>>illustrating more interesting features than one sees with
>>>>MailReader. In particular:
>>>>
>>>>* Use of application level "controller" features to filter out
>>>> direct requests for JSP and JSPF (JSP fragment) resources, since
>>>> they should only be accessed via *.faces URLs.
>>>>
>>>> See "src/web/WEB-INF/chain-config.xml" for configuration of
>>>> this application's additions to the standard Shale processing chain.
>>>>
>>>>* Use of DialogController for a sophisticated workflow with multiple
>>>> entries and exits: logon dialog for a portal-type site
>>>>that supports
>>>> creating new profiles (with or without an email confirmation), plus
>>>> "remember me" cookies.
>>>>
>>>> See the javadocs for package "org.apache.shale.usecases.logon" for
>>>> an overview of this functionality, plus an activity diagram
>>>>describing
>>>> the state transitions. (The diagram was produced with
>>>>Poseidon for UML
>>>> Community Edition, version 3.0, and the Poseidon project file is
>>>> also checked in).
>>>>
>>>>* Use of standard JSF facilities to support a language
>>>>picker, based on
>>>> the supported locales for the application. (NOTE - at
>>>>present switching
>>>> languages does not appear to do anything, but that is because I only
>>>> checked in the default (English) properties file -- if someone would
>>>> like to translate
>>>>"src/java/org/apache/shale/usecases/view/Bundle.properties"
>>>> into other languages, I'd be happy to check it in.
>>>>
>>>> See "src/web/locale/select.jsp" for the JSP page that does this,
>>>> and "src/java/org/apache/shale/usecases/locale/Select.java" for
>>>> the corresponding backing bean.
>>>>
>>>>* Use of <managed-property> elements to configure the properties of a
>>>> newly created managed bean, using either literal values or
>>>>expressions
>>>> (essentially an example of IoC with setter injection).
>>>> In this example, such properties are used to:
>>>> - Configure the DAO object that is used by the business logic of
>>>> the application, using
>>>> - Configure the functionality of the DialogController instance,
>>>> describing whether email confirmations and remember me cookies
>>>> should be enabled or not.
>>>>
>>>> See "src/web/WEB-INF/faces-config.xml" for configuration of
>>>>this feature.
>>>>
>>>>* General purpose "domains" object (cached in application
>>>>scope the first
>>>> time it is accessed) to provide localized lists of
>>>>SelectItem value/label
>>>> pairs (these provide the content for dropdown lists etc.).
>>>>
>>>> See "src/java/org/apache/shale/usecases/util/Domains.java"
>>>>
>>>>The Javadocs for this application will be published soon,
>>>>with a pointer on the Wiki, and nightly builds will commence
>>>>this evening.
>>>>
>>>>--------------------------------------------------------------
>>>>----------------------------------------------
>>>>
>>>>
>>>>Craig
>>>>
>>>>
>>>>
>>>>
>>>>
>>>.
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>.
>
>
>
RE: "Use Cases" Example Webapp for the Shale proposal
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
TilesViewHandler delegates restoreView() and createView()
to the ViewHandler that TilesViewHandler
is wrapping. So in this case ShaleViewHandler.
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: Thursday, January 06, 2005 6:01 PM
> To: MyFaces Development
> Subject: Re: "Use Cases" Example Webapp for the Shale proposal
>
>
> Note that Shale also includes its own ViewHandler extension,
> so this would be unlikely to work unless the MyFaces one delegates its
> createView() and restoreView() calls to the Shale version.
>
> In addition, the Tiles support is unlikely to work optimally
> until Shale addes support for ViewControllers on a Tile (or,
> more generally, on a JSF subview) -- a feature that is on my
> TODO list.
>
> Craig
>
>
> On Wed, 05 Jan 2005 08:59:49 -0700, BaTien Duong
> <du...@gmail.com> wrote:
> > Matthias Wessendorf wrote:
> >
> > >I just tried the nightly build and it works fine
> > >with MyFaces.
> > >
> > >What must be done to run this app with MyFaces?
> > >
> > >a) remove jsf files from RI
> > >b) add jar files from MyFaces example
> > > (not only myfaces.jar also others like commons-fileupload.jar)
> > >c) add MyFaces listener to web.xml
> > > (and rename net.sf -> org.apache)
> > >
> > >I also removed the work directory inside of my tomcat.
> > >
> > >Done!
> > >
> > >so now it is time to dig inside the sources
> > >for this app and Shale ;-)
> > >
> > >Cheers!
> > >Matthias
> > >
> > >
> > >
> > Matthias:
> >
> > Wow ;-) we are in an exiting time. Please try to see if the
> > JspTilesViewHandlerImpl work properly with Shale as an application
> > controller. I have not tried this but it is very important to know,
> > especially for those who work with myfaces.
> >
> > Thanks
> >
> > BaTien
> > DBGROUPS
> >
> > >>-----Original Message-----
> > >>Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEM
> > >>Sent: Tuesday, January 04, 2005 5:50 AM
> > >>To: Struts Developers List; MyFaces Development
> > >>Cc: MyFaces Discussion
> > >>Subject: "Use Cases" Example Webapp for the Shale proposal
> > >>
> > >>
> > >>(Cross posting because this topic has come up on all of
> the lists in
> > >>the last couple weeks.)
> > >>
> > >>I just committed into the Struts SVN repository a new example
> > >>application (struts-shale-usecases) that illustrate's the
> different
> > >>take that Shale has on how an application framework can be built
> > >>around JSF, including support for "dialog scope" (longer than a
> > >>request, but shorter than a session). I've updated the
> Shale wiki
> > >>page to contain pointers to the latest API documentation for both
> > >>Shale and the example app:
> > >>
> > >> http://wiki.apache.org/struts/StrutsShale
> > >>
> > >>and nightly builds of the example app will be available starting
> > >>tonight (pointer is on the Wiki page above).
> > >>
> > >>The commit message was over the max size allowed, so here's the
> > >>descriptive text:
> > >>--------------------------------------------------------------
> > >>----------------------------------------------
> > >>
> > >>Initial commit of an example application for Shale, illustrating
> > >>more interesting features than one sees with MailReader. In
> > >>particular:
> > >>
> > >>* Use of application level "controller" features to filter out
> > >> direct requests for JSP and JSPF (JSP fragment) resources, since
> > >> they should only be accessed via *.faces URLs.
> > >>
> > >> See "src/web/WEB-INF/chain-config.xml" for
> configuration of this
> > >> application's additions to the standard Shale processing chain.
> > >>
> > >>* Use of DialogController for a sophisticated workflow
> with multiple
> > >> entries and exits: logon dialog for a portal-type site that
> > >>supports
> > >> creating new profiles (with or without an email confirmation),
> > >>plus
> > >> "remember me" cookies.
> > >>
> > >> See the javadocs for package
> "org.apache.shale.usecases.logon" for
> > >> an overview of this functionality, plus an activity diagram
> > >>describing
> > >> the state transitions. (The diagram was produced with Poseidon
> > >>for UML
> > >> Community Edition, version 3.0, and the Poseidon project file is
> > >> also checked in).
> > >>
> > >>* Use of standard JSF facilities to support a language
> picker, based
> > >>on
> > >> the supported locales for the application. (NOTE - at present
> > >>switching
> > >> languages does not appear to do anything, but that is because I
> > >>only
> > >> checked in the default (English) properties file -- if
> someone would
> > >> like to translate
> > >>"src/java/org/apache/shale/usecases/view/Bundle.properties"
> > >> into other languages, I'd be happy to check it in.
> > >>
> > >> See "src/web/locale/select.jsp" for the JSP page that
> does this,
> > >> and "src/java/org/apache/shale/usecases/locale/Select.java" for
> > >> the corresponding backing bean.
> > >>
> > >>* Use of <managed-property> elements to configure the
> properties of
> > >>a
> > >> newly created managed bean, using either literal values or
> > >>expressions
> > >> (essentially an example of IoC with setter injection).
> > >> In this example, such properties are used to:
> > >> - Configure the DAO object that is used by the business logic of
> > >> the application, using
> > >> - Configure the functionality of the DialogController instance,
> > >> describing whether email confirmations and remember me cookies
> > >> should be enabled or not.
> > >>
> > >> See "src/web/WEB-INF/faces-config.xml" for
> configuration of this
> > >>feature.
> > >>
> > >>* General purpose "domains" object (cached in application
> scope the
> > >>first
> > >> time it is accessed) to provide localized lists of SelectItem
> > >>value/label
> > >> pairs (these provide the content for dropdown lists etc.).
> > >>
> > >> See "src/java/org/apache/shale/usecases/util/Domains.java"
> > >>
> > >>The Javadocs for this application will be published soon, with a
> > >>pointer on the Wiki, and nightly builds will commence
> this evening.
> > >>
> > >>--------------------------------------------------------------
> > >>----------------------------------------------
> > >>
> > >>
> > >>Craig
> > >>
> > >>
> > >>
> > >
> > >.
> > >
> > >
> > >
> >
> >
>
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by Craig McClanahan <cr...@gmail.com>.
Note that Shale also includes its own ViewHandler extension, so this
would be unlikely to work unless the MyFaces one delegates its
createView() and restoreView() calls to the Shale version.
In addition, the Tiles support is unlikely to work optimally until
Shale addes support for ViewControllers on a Tile (or, more generally,
on a JSF subview) -- a feature that is on my TODO list.
Craig
On Wed, 05 Jan 2005 08:59:49 -0700, BaTien Duong <du...@gmail.com> wrote:
> Matthias Wessendorf wrote:
>
> >I just tried the nightly build and it works fine
> >with MyFaces.
> >
> >What must be done to run this app with MyFaces?
> >
> >a) remove jsf files from RI
> >b) add jar files from MyFaces example
> > (not only myfaces.jar also others like commons-fileupload.jar)
> >c) add MyFaces listener to web.xml
> > (and rename net.sf -> org.apache)
> >
> >I also removed the work directory inside of my tomcat.
> >
> >Done!
> >
> >so now it is time to dig inside the sources
> >for this app and Shale ;-)
> >
> >Cheers!
> >Matthias
> >
> >
> >
> Matthias:
>
> Wow ;-) we are in an exiting time. Please try to see if the
> JspTilesViewHandlerImpl work properly with Shale as an application
> controller. I have not tried this but it is very important to know,
> especially for those who work with myfaces.
>
> Thanks
>
> BaTien
> DBGROUPS
>
> >>-----Original Message-----
> >>Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEM
> >>Sent: Tuesday, January 04, 2005 5:50 AM
> >>To: Struts Developers List; MyFaces Development
> >>Cc: MyFaces Discussion
> >>Subject: "Use Cases" Example Webapp for the Shale proposal
> >>
> >>
> >>(Cross posting because this topic has come up on all of the
> >>lists in the last couple weeks.)
> >>
> >>I just committed into the Struts SVN repository a new example
> >>application (struts-shale-usecases) that illustrate's the
> >>different take that Shale has on how an application framework
> >>can be built around JSF, including support for "dialog scope"
> >>(longer than a request, but shorter than a session). I've
> >>updated the Shale wiki page to contain pointers to the latest
> >>API documentation for both Shale and the example app:
> >>
> >> http://wiki.apache.org/struts/StrutsShale
> >>
> >>and nightly builds of the example app will be available
> >>starting tonight (pointer is on the Wiki page above).
> >>
> >>The commit message was over the max size allowed, so here's
> >>the descriptive text:
> >>--------------------------------------------------------------
> >>----------------------------------------------
> >>
> >>Initial commit of an example application for Shale,
> >>illustrating more interesting features than one sees with
> >>MailReader. In particular:
> >>
> >>* Use of application level "controller" features to filter out
> >> direct requests for JSP and JSPF (JSP fragment) resources, since
> >> they should only be accessed via *.faces URLs.
> >>
> >> See "src/web/WEB-INF/chain-config.xml" for configuration of
> >> this application's additions to the standard Shale processing chain.
> >>
> >>* Use of DialogController for a sophisticated workflow with multiple
> >> entries and exits: logon dialog for a portal-type site
> >>that supports
> >> creating new profiles (with or without an email confirmation), plus
> >> "remember me" cookies.
> >>
> >> See the javadocs for package "org.apache.shale.usecases.logon" for
> >> an overview of this functionality, plus an activity diagram
> >>describing
> >> the state transitions. (The diagram was produced with
> >>Poseidon for UML
> >> Community Edition, version 3.0, and the Poseidon project file is
> >> also checked in).
> >>
> >>* Use of standard JSF facilities to support a language
> >>picker, based on
> >> the supported locales for the application. (NOTE - at
> >>present switching
> >> languages does not appear to do anything, but that is because I only
> >> checked in the default (English) properties file -- if someone would
> >> like to translate
> >>"src/java/org/apache/shale/usecases/view/Bundle.properties"
> >> into other languages, I'd be happy to check it in.
> >>
> >> See "src/web/locale/select.jsp" for the JSP page that does this,
> >> and "src/java/org/apache/shale/usecases/locale/Select.java" for
> >> the corresponding backing bean.
> >>
> >>* Use of <managed-property> elements to configure the properties of a
> >> newly created managed bean, using either literal values or
> >>expressions
> >> (essentially an example of IoC with setter injection).
> >> In this example, such properties are used to:
> >> - Configure the DAO object that is used by the business logic of
> >> the application, using
> >> - Configure the functionality of the DialogController instance,
> >> describing whether email confirmations and remember me cookies
> >> should be enabled or not.
> >>
> >> See "src/web/WEB-INF/faces-config.xml" for configuration of
> >>this feature.
> >>
> >>* General purpose "domains" object (cached in application
> >>scope the first
> >> time it is accessed) to provide localized lists of
> >>SelectItem value/label
> >> pairs (these provide the content for dropdown lists etc.).
> >>
> >> See "src/java/org/apache/shale/usecases/util/Domains.java"
> >>
> >>The Javadocs for this application will be published soon,
> >>with a pointer on the Wiki, and nightly builds will commence
> >>this evening.
> >>
> >>--------------------------------------------------------------
> >>----------------------------------------------
> >>
> >>
> >>Craig
> >>
> >>
> >>
> >
> >.
> >
> >
> >
>
>
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by BaTien Duong <du...@gmail.com>.
Thanks Matthias. We have great community and can lean on each other. If
i have some time i will look into it and will report back to the
community. Hope myfaces will pass the TCK soon.
BaTien
DBGROUPS
Matthias Wessendorf wrote:
>BaTien,
>
>no, it doesn't work. :(
>
>
>What I did:
>
>1) changed faces-config.xml of Shale-UseCases-Sample
> (added TilesViewHandler)
>2) changed web.xml
> (added tiles.xml as Context Parameter)
>3) added Struts.jar to web-inf/lib
>4) *wrapped* /usecases.jsp (aka usecases.faces)
> in tiles.xml like:
> <definition name="uscases.tiles" path="/uscases.jsp" />
>
>
>I don't see, what I missed...
>but it was only a short try.
>
>Perhaps I look deeper into it
>next days.
>
>BTW. here is the message from tomcat...
>
>ERROR:
>HTTP Status 500 -
>
>type Exception report
>
>message
>
>description The server encountered an internal error () that prevented
>it from fulfilling this request.
>
>exception
>
>javax.servlet.ServletException
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:129)
>
>org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java
>:670)
>
>org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:6
>37)
> org.apache.jsp.index_jsp._jspService(index_jsp.java:45)
>
>org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
>va:324)
>
>org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>
>org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
>
>org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
>
>org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF
>ilter.java:225)
>
>root cause
>
>java.lang.NullPointerException
>
>org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl.renderView(Js
>pTilesViewHandlerImpl.java:199)
>
>org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:290
>)
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)
>
>org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java
>:670)
>
>org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:6
>37)
> org.apache.jsp.index_jsp._jspService(index_jsp.java:45)
>
>org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
>va:324)
>
>org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
>
>org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
>
>org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
>
>org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF
>ilter.java:225)
>
>
>
>>-----Original Message-----
>>From: BaTien Duong [mailto:duong.batien@gmail.com]
>>Sent: Wednesday, January 05, 2005 5:00 PM
>>To: MyFaces Development
>>Subject: Re: "Use Cases" Example Webapp for the Shale proposal
>>
>>
>>Matthias Wessendorf wrote:
>>
>>
>>
>>>I just tried the nightly build and it works fine
>>>with MyFaces.
>>>
>>>What must be done to run this app with MyFaces?
>>>
>>>a) remove jsf files from RI
>>>b) add jar files from MyFaces example
>>> (not only myfaces.jar also others like commons-fileupload.jar)
>>>c) add MyFaces listener to web.xml
>>> (and rename net.sf -> org.apache)
>>>
>>>I also removed the work directory inside of my tomcat.
>>>
>>>Done!
>>>
>>>so now it is time to dig inside the sources
>>>for this app and Shale ;-)
>>>
>>>Cheers!
>>>Matthias
>>>
>>>
>>>
>>>
>>>
>>Matthias:
>>
>>Wow ;-) we are in an exiting time. Please try to see if the
>>JspTilesViewHandlerImpl work properly with Shale as an application
>>controller. I have not tried this but it is very important to know,
>>especially for those who work with myfaces.
>>
>>Thanks
>>
>>BaTien
>>DBGROUPS
>>
>>
>>
>>>>-----Original Message-----
>>>>From: Craig McClanahan [mailto:craigmcc@gmail.com]
>>>>Sent: Tuesday, January 04, 2005 5:50 AM
>>>>To: Struts Developers List; MyFaces Development
>>>>Cc: MyFaces Discussion
>>>>Subject: "Use Cases" Example Webapp for the Shale proposal
>>>>
>>>>
>>>>(Cross posting because this topic has come up on all of the
>>>>lists in the last couple weeks.)
>>>>
>>>>I just committed into the Struts SVN repository a new example
>>>>application (struts-shale-usecases) that illustrate's the
>>>>different take that Shale has on how an application framework
>>>>can be built around JSF, including support for "dialog scope"
>>>>(longer than a request, but shorter than a session). I've
>>>>updated the Shale wiki page to contain pointers to the latest
>>>>API documentation for both Shale and the example app:
>>>>
>>>> http://wiki.apache.org/struts/StrutsShale
>>>>
>>>>and nightly builds of the example app will be available
>>>>starting tonight (pointer is on the Wiki page above).
>>>>
>>>>The commit message was over the max size allowed, so here's
>>>>the descriptive text:
>>>>--------------------------------------------------------------
>>>>----------------------------------------------
>>>>
>>>>Initial commit of an example application for Shale,
>>>>illustrating more interesting features than one sees with
>>>>MailReader. In particular:
>>>>
>>>>* Use of application level "controller" features to filter out
>>>> direct requests for JSP and JSPF (JSP fragment) resources, since
>>>> they should only be accessed via *.faces URLs.
>>>>
>>>> See "src/web/WEB-INF/chain-config.xml" for configuration of this
>>>>application's additions to the standard Shale processing chain.
>>>>
>>>>* Use of DialogController for a sophisticated workflow with multiple
>>>> entries and exits: logon dialog for a portal-type site
>>>>that supports
>>>> creating new profiles (with or without an email
>>>>
>>>>
>>confirmation), plus
>>
>>
>>>> "remember me" cookies.
>>>>
>>>> See the javadocs for package "org.apache.shale.usecases.logon" for
>>>> an overview of this functionality, plus an activity diagram
>>>>describing
>>>> the state transitions. (The diagram was produced with
>>>>Poseidon for UML
>>>> Community Edition, version 3.0, and the Poseidon project file is
>>>> also checked in).
>>>>
>>>>* Use of standard JSF facilities to support a language
>>>>picker, based on
>>>> the supported locales for the application. (NOTE - at
>>>>present switching
>>>> languages does not appear to do anything, but that is
>>>>
>>>>
>>because I only
>>
>>
>>>> checked in the default (English) properties file -- if
>>>>
>>>>
>>someone would
>>
>>
>>>> like to translate
>>>>"src/java/org/apache/shale/usecases/view/Bundle.properties"
>>>> into other languages, I'd be happy to check it in.
>>>>
>>>> See "src/web/locale/select.jsp" for the JSP page that does this,
>>>>and
>>>>
>>>>
>>"src/java/org/apache/shale/usecases/locale/Select.java" for the
>>
>>
>>>>corresponding backing bean.
>>>>
>>>>* Use of <managed-property> elements to configure the
>>>>
>>>>
>>properties of a
>>
>>
>>>> newly created managed bean, using either literal values or
>>>>expressions
>>>> (essentially an example of IoC with setter injection).
>>>> In this example, such properties are used to:
>>>> - Configure the DAO object that is used by the business logic of
>>>> the application, using
>>>> - Configure the functionality of the DialogController instance,
>>>> describing whether email confirmations and remember me cookies
>>>> should be enabled or not.
>>>>
>>>> See "src/web/WEB-INF/faces-config.xml" for configuration of
>>>>this feature.
>>>>
>>>>* General purpose "domains" object (cached in application
>>>>scope the first
>>>> time it is accessed) to provide localized lists of
>>>>SelectItem value/label
>>>> pairs (these provide the content for dropdown lists etc.).
>>>>
>>>> See "src/java/org/apache/shale/usecases/util/Domains.java"
>>>>
>>>>The Javadocs for this application will be published soon,
>>>>with a pointer on the Wiki, and nightly builds will commence
>>>>this evening.
>>>>
>>>>--------------------------------------------------------------
>>>>----------------------------------------------
>>>>
>>>>
>>>>Craig
>>>>
>>>>
>>>>
>>>>
>>>>
>>>.
>>>
>>>
>>>
>>>
>>>
>
>.
>
>
>
RE: "Use Cases" Example Webapp for the Shale proposal
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
BaTien,
no, it doesn't work. :(
What I did:
1) changed faces-config.xml of Shale-UseCases-Sample
(added TilesViewHandler)
2) changed web.xml
(added tiles.xml as Context Parameter)
3) added Struts.jar to web-inf/lib
4) *wrapped* /usecases.jsp (aka usecases.faces)
in tiles.xml like:
<definition name="uscases.tiles" path="/uscases.jsp" />
I don't see, what I missed...
but it was only a short try.
Perhaps I look deeper into it
next days.
BTW. here is the message from tomcat...
ERROR:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
javax.servlet.ServletException
javax.faces.webapp.FacesServlet.service(FacesServlet.java:129)
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java
:670)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:6
37)
org.apache.jsp.index_jsp._jspService(index_jsp.java:45)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:324)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF
ilter.java:225)
root cause
java.lang.NullPointerException
org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl.renderView(Js
pTilesViewHandlerImpl.java:199)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:290
)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java
:670)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:6
37)
org.apache.jsp.index_jsp._jspService(index_jsp.java:45)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:324)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF
ilter.java:225)
> -----Original Message-----
> From: BaTien Duong [mailto:duong.batien@gmail.com]
> Sent: Wednesday, January 05, 2005 5:00 PM
> To: MyFaces Development
> Subject: Re: "Use Cases" Example Webapp for the Shale proposal
>
>
> Matthias Wessendorf wrote:
>
> >I just tried the nightly build and it works fine
> >with MyFaces.
> >
> >What must be done to run this app with MyFaces?
> >
> >a) remove jsf files from RI
> >b) add jar files from MyFaces example
> > (not only myfaces.jar also others like commons-fileupload.jar)
> >c) add MyFaces listener to web.xml
> > (and rename net.sf -> org.apache)
> >
> >I also removed the work directory inside of my tomcat.
> >
> >Done!
> >
> >so now it is time to dig inside the sources
> >for this app and Shale ;-)
> >
> >Cheers!
> >Matthias
> >
> >
> >
> Matthias:
>
> Wow ;-) we are in an exiting time. Please try to see if the
> JspTilesViewHandlerImpl work properly with Shale as an application
> controller. I have not tried this but it is very important to know,
> especially for those who work with myfaces.
>
> Thanks
>
> BaTien
> DBGROUPS
>
> >>-----Original Message-----
> >>From: Craig McClanahan [mailto:craigmcc@gmail.com]
> >>Sent: Tuesday, January 04, 2005 5:50 AM
> >>To: Struts Developers List; MyFaces Development
> >>Cc: MyFaces Discussion
> >>Subject: "Use Cases" Example Webapp for the Shale proposal
> >>
> >>
> >>(Cross posting because this topic has come up on all of the
> >>lists in the last couple weeks.)
> >>
> >>I just committed into the Struts SVN repository a new example
> >>application (struts-shale-usecases) that illustrate's the
> >>different take that Shale has on how an application framework
> >>can be built around JSF, including support for "dialog scope"
> >>(longer than a request, but shorter than a session). I've
> >>updated the Shale wiki page to contain pointers to the latest
> >>API documentation for both Shale and the example app:
> >>
> >> http://wiki.apache.org/struts/StrutsShale
> >>
> >>and nightly builds of the example app will be available
> >>starting tonight (pointer is on the Wiki page above).
> >>
> >>The commit message was over the max size allowed, so here's
> >>the descriptive text:
> >>--------------------------------------------------------------
> >>----------------------------------------------
> >>
> >>Initial commit of an example application for Shale,
> >>illustrating more interesting features than one sees with
> >>MailReader. In particular:
> >>
> >>* Use of application level "controller" features to filter out
> >> direct requests for JSP and JSPF (JSP fragment) resources, since
> >> they should only be accessed via *.faces URLs.
> >>
> >> See "src/web/WEB-INF/chain-config.xml" for configuration of this
> >> application's additions to the standard Shale processing chain.
> >>
> >>* Use of DialogController for a sophisticated workflow with multiple
> >> entries and exits: logon dialog for a portal-type site
> >>that supports
> >> creating new profiles (with or without an email
> confirmation), plus
> >> "remember me" cookies.
> >>
> >> See the javadocs for package "org.apache.shale.usecases.logon" for
> >> an overview of this functionality, plus an activity diagram
> >>describing
> >> the state transitions. (The diagram was produced with
> >>Poseidon for UML
> >> Community Edition, version 3.0, and the Poseidon project file is
> >> also checked in).
> >>
> >>* Use of standard JSF facilities to support a language
> >>picker, based on
> >> the supported locales for the application. (NOTE - at
> >>present switching
> >> languages does not appear to do anything, but that is
> because I only
> >> checked in the default (English) properties file -- if
> someone would
> >> like to translate
> >>"src/java/org/apache/shale/usecases/view/Bundle.properties"
> >> into other languages, I'd be happy to check it in.
> >>
> >> See "src/web/locale/select.jsp" for the JSP page that does this,
> >> and
> "src/java/org/apache/shale/usecases/locale/Select.java" for the
> >> corresponding backing bean.
> >>
> >>* Use of <managed-property> elements to configure the
> properties of a
> >> newly created managed bean, using either literal values or
> >>expressions
> >> (essentially an example of IoC with setter injection).
> >> In this example, such properties are used to:
> >> - Configure the DAO object that is used by the business logic of
> >> the application, using
> >> - Configure the functionality of the DialogController instance,
> >> describing whether email confirmations and remember me cookies
> >> should be enabled or not.
> >>
> >> See "src/web/WEB-INF/faces-config.xml" for configuration of
> >>this feature.
> >>
> >>* General purpose "domains" object (cached in application
> >>scope the first
> >> time it is accessed) to provide localized lists of
> >>SelectItem value/label
> >> pairs (these provide the content for dropdown lists etc.).
> >>
> >> See "src/java/org/apache/shale/usecases/util/Domains.java"
> >>
> >>The Javadocs for this application will be published soon,
> >>with a pointer on the Wiki, and nightly builds will commence
> >>this evening.
> >>
> >>--------------------------------------------------------------
> >>----------------------------------------------
> >>
> >>
> >>Craig
> >>
> >>
> >>
> >
> >.
> >
> >
> >
>
Re: "Use Cases" Example Webapp for the Shale proposal
Posted by BaTien Duong <du...@gmail.com>.
Matthias Wessendorf wrote:
>I just tried the nightly build and it works fine
>with MyFaces.
>
>What must be done to run this app with MyFaces?
>
>a) remove jsf files from RI
>b) add jar files from MyFaces example
> (not only myfaces.jar also others like commons-fileupload.jar)
>c) add MyFaces listener to web.xml
> (and rename net.sf -> org.apache)
>
>I also removed the work directory inside of my tomcat.
>
>Done!
>
>so now it is time to dig inside the sources
>for this app and Shale ;-)
>
>Cheers!
>Matthias
>
>
>
Matthias:
Wow ;-) we are in an exiting time. Please try to see if the
JspTilesViewHandlerImpl work properly with Shale as an application
controller. I have not tried this but it is very important to know,
especially for those who work with myfaces.
Thanks
BaTien
DBGROUPS
>>-----Original Message-----
>>From: Craig McClanahan [mailto:craigmcc@gmail.com]
>>Sent: Tuesday, January 04, 2005 5:50 AM
>>To: Struts Developers List; MyFaces Development
>>Cc: MyFaces Discussion
>>Subject: "Use Cases" Example Webapp for the Shale proposal
>>
>>
>>(Cross posting because this topic has come up on all of the
>>lists in the last couple weeks.)
>>
>>I just committed into the Struts SVN repository a new example
>>application (struts-shale-usecases) that illustrate's the
>>different take that Shale has on how an application framework
>>can be built around JSF, including support for "dialog scope"
>>(longer than a request, but shorter than a session). I've
>>updated the Shale wiki page to contain pointers to the latest
>>API documentation for both Shale and the example app:
>>
>> http://wiki.apache.org/struts/StrutsShale
>>
>>and nightly builds of the example app will be available
>>starting tonight (pointer is on the Wiki page above).
>>
>>The commit message was over the max size allowed, so here's
>>the descriptive text:
>>--------------------------------------------------------------
>>----------------------------------------------
>>
>>Initial commit of an example application for Shale,
>>illustrating more interesting features than one sees with
>>MailReader. In particular:
>>
>>* Use of application level "controller" features to filter out
>> direct requests for JSP and JSPF (JSP fragment) resources, since
>> they should only be accessed via *.faces URLs.
>>
>> See "src/web/WEB-INF/chain-config.xml" for configuration of
>> this application's additions to the standard Shale processing chain.
>>
>>* Use of DialogController for a sophisticated workflow with multiple
>> entries and exits: logon dialog for a portal-type site
>>that supports
>> creating new profiles (with or without an email confirmation), plus
>> "remember me" cookies.
>>
>> See the javadocs for package "org.apache.shale.usecases.logon" for
>> an overview of this functionality, plus an activity diagram
>>describing
>> the state transitions. (The diagram was produced with
>>Poseidon for UML
>> Community Edition, version 3.0, and the Poseidon project file is
>> also checked in).
>>
>>* Use of standard JSF facilities to support a language
>>picker, based on
>> the supported locales for the application. (NOTE - at
>>present switching
>> languages does not appear to do anything, but that is because I only
>> checked in the default (English) properties file -- if someone would
>> like to translate
>>"src/java/org/apache/shale/usecases/view/Bundle.properties"
>> into other languages, I'd be happy to check it in.
>>
>> See "src/web/locale/select.jsp" for the JSP page that does this,
>> and "src/java/org/apache/shale/usecases/locale/Select.java" for
>> the corresponding backing bean.
>>
>>* Use of <managed-property> elements to configure the properties of a
>> newly created managed bean, using either literal values or
>>expressions
>> (essentially an example of IoC with setter injection).
>> In this example, such properties are used to:
>> - Configure the DAO object that is used by the business logic of
>> the application, using
>> - Configure the functionality of the DialogController instance,
>> describing whether email confirmations and remember me cookies
>> should be enabled or not.
>>
>> See "src/web/WEB-INF/faces-config.xml" for configuration of
>>this feature.
>>
>>* General purpose "domains" object (cached in application
>>scope the first
>> time it is accessed) to provide localized lists of
>>SelectItem value/label
>> pairs (these provide the content for dropdown lists etc.).
>>
>> See "src/java/org/apache/shale/usecases/util/Domains.java"
>>
>>The Javadocs for this application will be published soon,
>>with a pointer on the Wiki, and nightly builds will commence
>>this evening.
>>
>>--------------------------------------------------------------
>>----------------------------------------------
>>
>>
>>Craig
>>
>>
>>
>
>.
>
>
>
RE: "Use Cases" Example Webapp for the Shale proposal
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
I just tried the nightly build and it works fine
with MyFaces.
What must be done to run this app with MyFaces?
a) remove jsf files from RI
b) add jar files from MyFaces example
(not only myfaces.jar also others like commons-fileupload.jar)
c) add MyFaces listener to web.xml
(and rename net.sf -> org.apache)
I also removed the work directory inside of my tomcat.
Done!
so now it is time to dig inside the sources
for this app and Shale ;-)
Cheers!
Matthias
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: Tuesday, January 04, 2005 5:50 AM
> To: Struts Developers List; MyFaces Development
> Cc: MyFaces Discussion
> Subject: "Use Cases" Example Webapp for the Shale proposal
>
>
> (Cross posting because this topic has come up on all of the
> lists in the last couple weeks.)
>
> I just committed into the Struts SVN repository a new example
> application (struts-shale-usecases) that illustrate's the
> different take that Shale has on how an application framework
> can be built around JSF, including support for "dialog scope"
> (longer than a request, but shorter than a session). I've
> updated the Shale wiki page to contain pointers to the latest
> API documentation for both Shale and the example app:
>
> http://wiki.apache.org/struts/StrutsShale
>
> and nightly builds of the example app will be available
> starting tonight (pointer is on the Wiki page above).
>
> The commit message was over the max size allowed, so here's
> the descriptive text:
> --------------------------------------------------------------
> ----------------------------------------------
>
> Initial commit of an example application for Shale,
> illustrating more interesting features than one sees with
> MailReader. In particular:
>
> * Use of application level "controller" features to filter out
> direct requests for JSP and JSPF (JSP fragment) resources, since
> they should only be accessed via *.faces URLs.
>
> See "src/web/WEB-INF/chain-config.xml" for configuration of
> this application's additions to the standard Shale processing chain.
>
> * Use of DialogController for a sophisticated workflow with multiple
> entries and exits: logon dialog for a portal-type site
> that supports
> creating new profiles (with or without an email confirmation), plus
> "remember me" cookies.
>
> See the javadocs for package "org.apache.shale.usecases.logon" for
> an overview of this functionality, plus an activity diagram
> describing
> the state transitions. (The diagram was produced with
> Poseidon for UML
> Community Edition, version 3.0, and the Poseidon project file is
> also checked in).
>
> * Use of standard JSF facilities to support a language
> picker, based on
> the supported locales for the application. (NOTE - at
> present switching
> languages does not appear to do anything, but that is because I only
> checked in the default (English) properties file -- if someone would
> like to translate
> "src/java/org/apache/shale/usecases/view/Bundle.properties"
> into other languages, I'd be happy to check it in.
>
> See "src/web/locale/select.jsp" for the JSP page that does this,
> and "src/java/org/apache/shale/usecases/locale/Select.java" for
> the corresponding backing bean.
>
> * Use of <managed-property> elements to configure the properties of a
> newly created managed bean, using either literal values or
> expressions
> (essentially an example of IoC with setter injection).
> In this example, such properties are used to:
> - Configure the DAO object that is used by the business logic of
> the application, using
> - Configure the functionality of the DialogController instance,
> describing whether email confirmations and remember me cookies
> should be enabled or not.
>
> See "src/web/WEB-INF/faces-config.xml" for configuration of
> this feature.
>
> * General purpose "domains" object (cached in application
> scope the first
> time it is accessed) to provide localized lists of
> SelectItem value/label
> pairs (these provide the content for dropdown lists etc.).
>
> See "src/java/org/apache/shale/usecases/util/Domains.java"
>
> The Javadocs for this application will be published soon,
> with a pointer on the Wiki, and nightly builds will commence
> this evening.
>
> --------------------------------------------------------------
> ----------------------------------------------
>
>
> Craig
>