Re: svn commit: r465991 - in /shale/framework/trunk: shale-application/src/site/ shale-application/src/site/xdoc/ shale-apps/src/site/ shale-clay/src/site/ shale-core/src/site/ shale-remoting/src/site
On 10/19/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 10/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > NOTE -- I am not deleting the now-obsolete feature-xxx.xml pages yet ... > that needs to be coordinated with installing redirects on the website so > that the existing links in the world do not get broken. Oops... I already deleted two of them last week without redirecting. OK, I've installed redirects (an .htaccess file in /www/shale.apache.org) for the application, dialog, remoting, test, tiger, and view subprojects. I'll delete the corresponding features files tomorrow, after verifying that the web site has been updated and correctly does the redirects. Craig -- Wendy
Re: svn commit: r465991 - in /shale/framework/trunk: shale-application/src/site/ shale-application/src/site/xdoc/ shale-apps/src/site/ shale-clay/src/site/ shale-core/src/site/ shale-remoting/src/site
On 10/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: NOTE -- I am not deleting the now-obsolete feature-xxx.xml pages yet ... that needs to be coordinated with installing redirects on the website so that the existing links in the world do not get broken. Oops... I already deleted two of them last week without redirecting. -- Wendy
Re: Website questions
I seem to recall that we did this manually for the MyFaces site way back when. That pretty much sucked but the site stuff was fairly new. I know there was some work that allowed you to make sites for subprojects and maven was supposed to chain them all together. Maybe its usable now? Try taking a look at how the MyFaces site works. We use symlinks and a few little tricks but the end result is pretty much what we want for Shale. Sean On 10/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: I've been fleshing out the "front page" docs of several of the new subproject modules[1][2][3], but on the actual site these pages don't have the overall banner and logo that the front page has. Shouldn't they? If so, what do we need to configure to make that happen? Craig [1] http://shale.apache.org/shale-dialog/index.html [2] http://shale.apache.org/shale-dialog-basic/index.html [3] http://shale.apache.org/shale-view/index.html
Website questions
I've been fleshing out the "front page" docs of several of the new subproject modules[1][2][3], but on the actual site these pages don't have the overall banner and logo that the front page has. Shouldn't they? If so, what do we need to configure to make that happen? Craig [1] http://shale.apache.org/shale-dialog/index.html [2] http://shale.apache.org/shale-dialog-basic/index.html [3] http://shale.apache.org/shale-view/index.html
RE: Shale home page
> > > Maybe it's something like a "meta-framework". It's not really a > > > "framework" as such because JSF is the framework. > > > But it is some missing parts that integrate fairly > seamlessly with > > > the JSF framework. Missing parts and added value - > things like Clay > > > and Dialog are added value. Things like the core ViewController > > > provide missing pieces to the core JSF framework. > > > > I like the way "meta-framework" sounds, but it implies > something more > > like Keel (http://www.keelframework.org). Shale's name provides the > > underpinnings for the verbage we need -- separate layers that can > > optionally be applied to your application. What's wrong with > > "services"? > > > The "one sentence" description I have been using lately that seems to > resonate: Shale is a set of loosely coupled application > framework services built on top of JSF." If need be, I also > emphasize that we're talking mostly about the "MVC > controller" part of JSF, and are agnostic about component > libraries. Use whatever visual components you'd like, and > use Shale's features to make the back end of your application > easier to compose. I think the one senetence explanation works quite well. "Loosely coupled" is key. > > > Of course as JSR-299 progresses we may find ourselves in > a different > > > category. There has been talk of building a > > > JSR-299 implementation when the time is right. > > > > I don't know if the category really changes. To me, that's just one > > more layer... > > > Agreed. So would a layer implementing the validation > annotations (303?) if/when it actually happens. True. I think there are lots of opportunities for continually adding value to JSF. Some if it will make it into the spec, and some won't. > Craig ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Release docs
We should probably make clear in the next release about how there is a new shale-application project and that you will need to change your pom.xml (to add a new dependency) and web.xml (to reflect the new listener package name). This tripped me up on my own app. Of course it was easy to fix since I knew these changes were in the works. Sean
Re: Shale home page
On 10/19/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: > On Oct 18, 2006, at 5:46 PM, David Geary wrote: > > > If not working on it, I've been thinking about the homepage lately, > > and it strikes me that I don't really know how to spin > Shale. We have > > so many unrelated features that it's difficult to say > "Shale is...". > > The addition of JPA makes things even murkier. Are we one-stop > > shopping for JSF? > > Proving > > ground for JSF 2.0? I know we're a set of services, but that's a > > rather bland description. > > I agree. Until about 4 months ago I only knew very little > about JSF. I had not actually written a JSF app. Now, I'm > in the middle of writing a pretty significant JSF app and > teaching our team of > developers how (and why) to use JSF. So I've gone in head > first :-) > Before I started this adventure I had a difficult time seeing > where Shale fit. Now I'm starting to see the plugin points > where it makes sense and hopefully we will start integrating > Shale into our app in the near future. > > Maybe it's something like a "meta-framework". It's not > really a "framework" as such because JSF is the framework. > But it is some missing parts that integrate fairly seamlessly > with the JSF framework. Missing parts and added value - > things like Clay and Dialog are added value. Things like the > core ViewController provide missing pieces to the core JSF > framework. I like the way "meta-framework" sounds, but it implies something more like Keel (http://www.keelframework.org). Shale's name provides the underpinnings for the verbage we need -- separate layers that can optionally be applied to your application. What's wrong with "services"? The "one sentence" description I have been using lately that seems to resonate: Shale is a set of loosely coupled application framework services built on top of JSF." If need be, I also emphasize that we're talking mostly about the "MVC controller" part of JSF, and are agnostic about component libraries. Use whatever visual components you'd like, and use Shale's features to make the back end of your application easier to compose. Maybe some of the missing pieces should be > submitted back as JSRs and we could work ourselves out of a > job in that sense. Or maybe not. Maybe they are not as > universally applicable as it seems at first glance. A lot of us JSF EG memebers are very familiar with Shale, so I'm pretty sure that features like the ViewController and Tiger annotations will make it into JSF 2.0 in some form. > Of course as JSR-299 progresses we may find ourselves in a > different category. There has been talk of building a > JSR-299 implementation when the time is right. I don't know if the category really changes. To me, that's just one more layer... Agreed. So would a layer implementing the validation annotations (303?) if/when it actually happens. Craig ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
RE: Shale home page
> On Oct 18, 2006, at 5:46 PM, David Geary wrote: > > > If not working on it, I've been thinking about the homepage lately, > > and it strikes me that I don't really know how to spin > Shale. We have > > so many unrelated features that it's difficult to say > "Shale is...". > > The addition of JPA makes things even murkier. Are we one-stop > > shopping for JSF? > > Proving > > ground for JSF 2.0? I know we're a set of services, but that's a > > rather bland description. > > I agree. Until about 4 months ago I only knew very little > about JSF. I had not actually written a JSF app. Now, I'm > in the middle of writing a pretty significant JSF app and > teaching our team of > developers how (and why) to use JSF. So I've gone in head > first :-) > Before I started this adventure I had a difficult time seeing > where Shale fit. Now I'm starting to see the plugin points > where it makes sense and hopefully we will start integrating > Shale into our app in the near future. > > Maybe it's something like a "meta-framework". It's not > really a "framework" as such because JSF is the framework. > But it is some missing parts that integrate fairly seamlessly > with the JSF framework. Missing parts and added value - > things like Clay and Dialog are added value. Things like the > core ViewController provide missing pieces to the core JSF > framework. I like the way "meta-framework" sounds, but it implies something more like Keel (http://www.keelframework.org). Shale's name provides the underpinnings for the verbage we need -- separate layers that can optionally be applied to your application. What's wrong with "services"? > Maybe some of the missing pieces should be > submitted back as JSRs and we could work ourselves out of a > job in that sense. Or maybe not. Maybe they are not as > universally applicable as it seems at first glance. A lot of us JSF EG memebers are very familiar with Shale, so I'm pretty sure that features like the ViewController and Tiger annotations will make it into JSF 2.0 in some form. > Of course as JSR-299 progresses we may find ourselves in a > different category. There has been talk of building a > JSR-299 implementation when the time is right. I don't know if the category really changes. To me, that's just one more layer... ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Re: Shale home page
On Oct 18, 2006, at 5:46 PM, David Geary wrote: If not working on it, I've been thinking about the homepage lately, and it strikes me that I don't really know how to spin Shale. We have so many unrelated features that it's difficult to say "Shale is...". The addition of JPA makes things even murkier. Are we one-stop shopping for JSF? Proving ground for JSF 2.0? I know we're a set of services, but that's a rather bland description. I agree. Until about 4 months ago I only knew very little about JSF. I had not actually written a JSF app. Now, I'm in the middle of writing a pretty significant JSF app and teaching our team of developers how (and why) to use JSF. So I've gone in head first :-) Before I started this adventure I had a difficult time seeing where Shale fit. Now I'm starting to see the plugin points where it makes sense and hopefully we will start integrating Shale into our app in the near future. Maybe it's something like a "meta-framework". It's not really a "framework" as such because JSF is the framework. But it is some missing parts that integrate fairly seamlessly with the JSF framework. Missing parts and added value - things like Clay and Dialog are added value. Things like the core ViewController provide missing pieces to the core JSF framework. Maybe some of the missing pieces should be submitted back as JSRs and we could work ourselves out of a job in that sense. Or maybe not. Maybe they are not as universally applicable as it seems at first glance. Of course as JSR-299 progresses we may find ourselves in a different category. There has been talk of building a JSR-299 implementation when the time is right. Greg
