You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Troy J. Kelley" <tr...@e-gineering.com> on 2006/01/30 20:48:08 UTC
Strategy for incorporating Shale w/JSF
I did my best to see if this was already addressed by searching mail archives. All I found so far is a comment from Craig here:
http://marc.theaimsgroup.com/?l=struts-user&m=112604395721097&w=2
Craig writes:
"If, on the other hand, you decide to commit to JSF's controller early rather than late, you might as well just use Shale along with it from the beginning. Unlike the way that other frameworks deal with JSF, Shale
*assumes* you will be using the JSF controller architecture, and it just adds ease of use around problems you'll face anyway. It doesn't try to treat JSF as purely a component architecture."
I'm in a situation where I'm consulting in a corporate environment. I really love what shale has to offer, but I'm concerned about adopting things a bit too early. I checked out the "API Stability" section of the project docs (http://struts.apache.org/struts-shale/api-stability.html - which is great, btw) and I'm trying to answer the question:
What components of shale can I integrate into a JSF app and get the biggest benefit from, without sacrificing stability at the functional and API level?
For instance, shale-core is a mixture of Developing and Evolving packages at both the Application and Framework level. If I'm writing and enterprise app that's going to production in 6 months, how do I choose wisely? :-)
I've included the start of a package dependency diagram that might help - it's incomplete. I figured somebody might know this by heart, and could finish it quickly :-) Feel free to distribute.
I've spent the past several days doing research on web app frameworks and JSF is a contender for *this environment* - but only becomes more promising with offerings like facelets and shale (IMHO).
Thanks,
-Troy
Troy J. Kelley
E-gineering, LLC
10401 North Meridian Street | Suite 150
Indianapolis, IN | 46290 | 317.616.3974
www.e-gineering.com
Re: Strategy for incorporating Shale w/JSF
Posted by Craig McClanahan <cr...@apache.org>.
On 1/30/06, Sergey Vlasov <vl...@gmail.com> wrote:
>
> Craig,
>
> Just wondering if you are planning to implement some kind of support for
> Shale-Clay in the next release of Sun Java Studio Creator?
It is one of the things we will be looking at, but no final decisions have
been made yet.
Regards,
> Sergey
Craig
Re: Strategy for incorporating Shale w/JSF
Posted by Sergey Vlasov <vl...@gmail.com>.
Craig,
Just wondering if you are planning to implement some kind of support for
Shale-Clay in the next release of Sun Java Studio Creator?
Regards,
Sergey
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for incorporating Shale w/JSF
Posted by Sergey Vlasov <vl...@gmail.com>.
Craig,
Just wondering if you are planning to implement some kind of support for
Shale-Clay in the next release of Sun Java Studio Creator?
Regards,
Sergey
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Strategy for incorporating Shale w/JSF
Posted by Craig McClanahan <cr...@apache.org>.
Inline.
On 1/30/06, Troy J. Kelley <tr...@e-gineering.com> wrote:
>
> I did my best to see if this was already addressed by searching mail
> archives. All I found so far is a comment from Craig here:
>
> http://marc.theaimsgroup.com/?l=struts-user&m=112604395721097&w=2
>
> Craig writes:
> "If, on the other hand, you decide to commit to JSF's controller early
> rather than late, you might as well just use Shale along with it from the
> beginning. Unlike the way that other frameworks deal with JSF, Shale
> *assumes* you will be using the JSF controller architecture, and it just
> adds ease of use around problems you'll face anyway. It doesn't try to treat
> JSF as purely a component architecture."
>
> I'm in a situation where I'm consulting in a corporate environment. I
> really love what shale has to offer, but I'm concerned about adopting things
> a bit too early. I checked out the "API Stability" section of the project
> docs (http://struts.apache.org/struts-shale/api-stability.html - which is
> great, btw)
Thanks ... I hope it nudges my fellow framework developers (both here and
other webapp projects) to provide the same sort of information.
and I'm trying to answer the question:
>
> What components of shale can I integrate into a JSF app and get the
> biggest benefit from, without sacrificing stability at the functional and
> API level?
>
> For instance, shale-core is a mixture of Developing and Evolving packages
> at both the Application and Framework level. If I'm writing and enterprise
> app that's going to production in 6 months, how do I choose wisely? :-)
The most conservative approach would be to use the following rules:
* Stay away from any package targeted as "Framework" ... that's for
modifying Shale itself, rather than using it. (If you find yourself
tempted to change things here, please file RFEs so we can make
the stuff you need a standard part of Shale).
* Stick with packages marked as "Stable" or "Evolving".
In practical terms, that means (as of today):
* The JSF components provided by Shale are only those needed
to integrate framework capabilities ... I don't forsee Shale itself
becoming a general repository for JSF components. Instead, it
should interoperate nicely with libraries like those from MyFaces.
* The ViewController APIs (org.apache.shale.view) that an application
requires are solid, although new features might get added later. One
reason for my confidence here is that Sun Java Studio Creator 2
(for which I'm the architect) provides very similar (paranoids would
say "suspiciously" similar :-) capabilities in the page beans that it
produces for you, and the paradigm seems to fit the proposed
application design pattern quite nicey.
* The dialog stuff (one of my favorite features) is marked as "Evolving"
not because I expect to break backwards compatibility, but because
some known deficiences need to be addressed (particularly in dealing
with more than one simulataneously active dialog) that *might* require
such changes. Even in that circumstance, I would strive to not break
old apps (one of the reasons Struts 1.x was and is popular is we were
really conservative about changes like this) ... but it's not yet clear
what we might need/want to do to finish this functionality.
* I'm pretty happy with the new remoting stuff (org.apache.shale.remoting)
but it's going to stay "Evolving" until someone actually *does* use it and
provides some feedback. Hows that Catch-22 for you? :-). (It also needs
better documentation ... in progress.)
* Do not assume that APIs marked "Developing" necessarily *will* break --
so depending on them shouldn't be dismissed out of hand. It's just that
the likelihood of needing adaptations here is slightly higher than
"Evolving"
packages.
I've included the start of a package dependency diagram that might help -
> it's incomplete. I figured somebody might know this by heart, and could
> finish it quickly :-) Feel free to distribute.
I don't see the attachment, but as long as you stick with the packages
targeted at *Application* deveopers rather than *Framework* developers, you
should not have to care about internal-to-Shale dependencies on the
framework stuff. That's our job to deal with any changes there. You should
focus on using the public application APIs only.
I've spent the past several days doing research on web app frameworks and
> JSF is a contender for *this environment* - but only becomes more promising
> with offerings like facelets and shale (IMHO).
Certainly looks like a contender to me :-).
And don't forget to look at the components over at
http://myfaces.apache.org-- they are doing some interesting things.
Much more comprehensive than the
sum total of all the UI-oriented JSP tag libraries I have looked at to
date. That's one of the benefits of a common base API.
Thanks,
> -Troy
Craig