Re: MyFaces And Tiles or SiteMesh?
Try using a Tiles controller to dynamically specify the tile's content, based on whatever it is your actions are doing. david Le 05-07-30 à 20:20, Curtney Jacobs a écrit : Greetings! This is my last attempt before giving up on Tiles for my current project. Has anyone successfully used Tiles and MyFaces in a project where action events triggers dynamic loading of tile definitions. For example, command link "A" trigger loading of tile definition "A", command link "B" trigger loading of tile definition "B", etc. I am aware that because my url address never changes I will continue to load the same tile definition. Is there anyway around that, using Tiles and MyFaces ofcourse. Not resorting to using I have tried redirecting, but my jsf view does not reflect the app current state, however, I do load the correct tile definition. I have tried dynamically setting a new view using code similar to the following: context.getApplication().getViewHandler().createView (context, "/myview.jsfp"); context.setViewRoot (view); context.renderResponse(); Perhaps, I should switch to SiteMesh? Has anyone encountered any problems using SiteMesh and MyFaces? Please, your feedback is greatly appreciated. Thanks, Curtney
Re: MyFaces And Tiles or SiteMesh?
Le 05-08-01 à 03:36, Curtney Jacobs a écrit : Greetings David. Ok, so would my conditional logic in my Tile controller be determined by parameters? Meaning, display this content if parameter xxx occured. It seems that this would be the only way my Tile controller would no what to do. For example, I suppose that'd work, but you're going to have to dig that parameter out of the JSF component hierarchy in your Tiles controller. I don't think I'd be comfortable with that coupling between the Tiles controller and the JSF component. It's hard to tell what you're up to from that puny example 8-), but I would probably be inclined to programatically set a variable, perhaps in request or session scope and let the controller base it's decision on that variable. You could set the variable in a JSF action or action listener. Anyway, regardless of how you do it, Tiles controllers exist mainly to dynamically specify tile defintions, (although they can certainly do other things) instead of statically in the Tiles config file. david Curtney On Sun, 2005-07-31 at 14:39 -0700, David Geary wrote: Try using a Tiles controller to dynamically specify the tile's content, based on whatever it is your actions are doing. david Le 05-07-30 à 20:20, Curtney Jacobs a écrit : Greetings! This is my last attempt before giving up on Tiles for my current project. Has anyone successfully used Tiles and MyFaces in a project where action events triggers dynamic loading of tile definitions. For example, command link "A" trigger loading of tile definition "A", command link "B" trigger loading of tile definition "B", etc. I am aware that because my url address never changes I will continue to load the same tile definition. Is there anyway around that, using Tiles and MyFaces ofcourse. Not resorting to using I have tried redirecting, but my jsf view does not reflect the app current state, however, I do load the correct tile definition. I have tried dynamically setting a new view using code similar to the following: context.getApplication().getViewHandler().createView (context, "/myview.jsfp"); context.setViewRoot (view); context.renderResponse(); Perhaps, I should switch to SiteMesh? Has anyone encountered any problems using SiteMesh and MyFaces? Please, your feedback is greatly appreciated. Thanks, Curtney
Re: MyFaces And Tiles or SiteMesh?
Le 05-08-10 à 04:55, Arash Bijanzadeh a écrit :What was the result of thread? Which one did you used Jacobs? Any news from sitemesh compatibility with MyFaces?SiteMesh, unfortunately, only half works with JSF. You can decorate a JSP page withJSF components, but you cannot have JSF components in the decorator itself. Also,you have to be careful about the order in which you declare your filters with MyFaces,or you're likely to get a blank page. Hopefully, those things will change in SiteMesh 3.0.Here's a blog entry that outlines the pitfalls of using SiteMesh with MyFaces: http://www.almaer.com/blog/archives/001010.htmldavidOn 8/1/05, Curtney Jacobs < [EMAIL PROTECTED]> wrote:Greetings David.Ok, so would my conditional logic in my Tile controller be determined by parameters? Meaning, display this content if parameter xxx occured. Itseems that this would be the only way my Tile controller would no whatto do.For example,value="MyWorkspace" target="_self">CurtneyOn Sun, 2005-07-31 at 14:39 -0700, David Geary wrote: > Try using a Tiles controller to dynamically specify the tile's> content, based on whatever it is your actions are doing.>>> david>> Le 05-07-30 à 20:20, Curtney Jacobs a écrit : >> > Greetings!> >> > This is my last attempt before giving up on Tiles for my current> > project. Has anyone successfully used Tiles and MyFaces in a project> > where action events triggers dynamic loading of tile definitions. For > > example, command link "A" trigger loading of tile definition "A",> > command link "B" trigger loading of tile definition "B", etc.> >> > I am aware that because my url address never changes I will > > continue to> > load the same tile definition. Is there anyway around that, using> > Tiles> > and MyFaces ofcourse. Not resorting to using > >> > > > I have tried redirecting, but my jsf view does not reflect the app> > current state, however, I do load the correct tile definition.> >> > I have tried dynamically setting a new view using code similar to the > > following:> >> > context.getApplication().getViewHandler().createView (context,> > "/myview.jsfp");> > context.setViewRoot (view);> > context.renderResponse ();> >> >> > Perhaps, I should switch to SiteMesh? Has anyone encountered any> > problems using SiteMesh and MyFaces?> >> >> > Please, your feedback is greatly appreciated. > >> > Thanks,> >> > Curtney> >> >>-- from debian manifesto:Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU.
Re: WebXml.init must be called before!
Nevermind, I figured out what's going on as soon as I hit the send button to send the email. But, hey, thanks anyway. 8-} david Le 05-08-26 à 17:49, David Geary a écrit : I'm trying to move an application from the RI to MyFaces. I've got the StartupServletContextListener specified in web.xml, but when I try to access the application, I get the following unpleasantness: javax.servlet.ServletException: org.apache.myfaces.webapp.webxml.WebXml.init must be called before! javax.faces.webapp.FacesServlet.service(FacesServlet.java:125) org.apache.shale.faces.ShaleApplicationFilter.doFilter (ShaleApplicationFilter.java:280) I have no idea what that message means (before *what*!?!) or what to do about it. Can anybody help me out? Thanks, david
WebXml.init must be called before!
I'm trying to move an application from the RI to MyFaces. I've got the StartupServletContextListener specified in web.xml, but when I try to access the application, I get the following unpleasantness: javax.servlet.ServletException: org.apache.myfaces.webapp.webxml.WebXml.init must be called before! javax.faces.webapp.FacesServlet.service(FacesServlet.java:125) org.apache.shale.faces.ShaleApplicationFilter.doFilter (ShaleApplicationFilter.java:280) I have no idea what that message means (before *what*!?!) or what to do about it. Can anybody help me out? Thanks, david
Re: h:outputLabel - validation and colons
Le Dec 1, 2004, à 7:33 PM, Matt Raible a écrit : Hello all, I've been doing a bit of MyFaces development this week and enjoying it for the most part. Glad to hear it Matt! 8-) I have a couple questions about : 1. Is there anyway to modify h:outputLabel to add an asterisk for required fields? You can do that without modifying h:outputLabel, for example: ... In your resource bundle: requiredNamePrompt=*Name Of course with that solution you're assuming the required state of the field in the view. That's probably better left to business logic, so you could do this instead: And BackingBean.getNamePrompt() would return the proper localized string, with an asterik if the property is required, and without an asterik otherwise. Or, you could do this: And have backingBean implement a boolean method named isNameRequired that returns the required status of the property in question. The h:outputText will only render if its rendered attribute is true. Do I have to subclass the existing JSP Tag to do this? You hardly ever want to subclass an existing component tag, because tags are really just thin veneers for component/renderer pairs. You could, however, implement your own Label renderer and plug it into h:outputLabel. But I would opt for one of the easier solutions above. 2. Is it possible to auto-add a colon? I'm able to do this pretty easily with a custom taglib and Commons Validator, but it seems difficult with MyFaces? With Tapestry, I can subclass the existing component and add my own suffix (including a space before the colon for the French locale). The same techniques for prepending an asterik will work for appending a colon. Again, you could implement your own Label renderer that does anything you want. david Thanks, Matt
Re: h:outputLabel - validation and colons
Le Dec 1, 2004, à 9:18 PM, Matt Raible a écrit : On Dec 1, 2004, at 8:40 PM, David Geary wrote: Le Dec 1, 2004, à 7:33 PM, Matt Raible a écrit : Hello all, I've been doing a bit of MyFaces development this week and enjoying it for the most part. Glad to hear it Matt! 8-) I have a couple questions about : 1. Is there anyway to modify h:outputLabel to add an asterisk for required fields? You can do that without modifying h:outputLabel, for example: ... In your resource bundle: requiredNamePrompt=*Name Of course with that solution you're assuming the required state of the field in the view. That's probably better left to business logic, so you could do this instead: And BackingBean.getNamePrompt() would return the proper localized string, with an asterik if the property is required, and without an asterik otherwise. Or, you could do this: And have backingBean implement a boolean method named isNameRequired that returns the required status of the property in question. The h:outputText will only render if its rendered attribute is true. Hmmm, sounds like I have to have a getter method for each form field on my managed bean? What a pain? Isn't there a way to look up if the field is required and just add a * - a solution that's generic for all outputLabel's? I'm willing to hack source code or create components if I need to - I just need to know 2 things: 1. Yes/No - if I have to hack the source to make the dynamic lookup possible? No hacking is required. 2. Where do I hack the source? I'm guessing there's some way to lookup the validation metadata for the inputs and use that data in the labels. You could implementing a replacement for the Label renderer: 1. In a renderer method such as encodeBegin(), get the value of the renderer's component (encodeBegin is passed the component. Call the component's getValue method). In this case, the component is the label and the value is the id of the labeled component. 2. Get a reference to the labeled component. In a JSF component hierarchy, any component can find any other component in the hierarchy with the findComponent(String) method, where the String is the component's id. So the label can find the labeled component. 3. Find out if the labeled component is required. Input components implement the editableValueHolder interface, which defines an isRequired method. 4. Render according to whether the labeled component is required. david Thanks, Matt Do I have to subclass the existing JSP Tag to do this? You hardly ever want to subclass an existing component tag, because tags are really just thin veneers for component/renderer pairs. You could, however, implement your own Label renderer and plug it into h:outputLabel. But I would opt for one of the easier solutions above. 2. Is it possible to auto-add a colon? I'm able to do this pretty easily with a custom taglib and Commons Validator, but it seems difficult with MyFaces? With Tapestry, I can subclass the existing component and add my own suffix (including a space before the colon for the French locale). The same techniques for prepending an asterik will work for appending a colon. Again, you could implement your own Label renderer that does anything you want. david Thanks, Matt
Re: h:outputLabel - validation and colons
Le Dec 1, 2004, à 9:42 PM, David Geary a écrit :
[snip]
Hmmm, sounds like I have to have a getter method for each form field
on my managed bean? What a pain?
Isn't there a way to look up if the field is required and just add a
* - a solution that's generic for all outputLabel's? I'm willing to
hack source code or create components if I need to - I just need to
know 2 things:
1. Yes/No - if I have to hack the source to make the dynamic lookup
possible?
No hacking is required.
2. Where do I hack the source? I'm guessing there's some way to
lookup the validation metadata for the inputs and use that data in
the labels.
You could implementing a replacement for the Label renderer:
1. In a renderer method such as encodeBegin(), get the value of the
renderer's component (encodeBegin is passed the component. Call the
component's getValue method). In this case, the component is the label
and the value is the id of the labeled component.
2. Get a reference to the labeled component. In a JSF component
hierarchy, any component can find any other component in the hierarchy
with the findComponent(String) method, where the String is the
component's id. So the label can find the labeled component.
3. Find out if the labeled component is required. Input components
implement the editableValueHolder interface, which defines an
isRequired method.
4. Render according to whether the labeled component is required.
david
I went ahead and implemented this. After replacing the standard Label
renderer, this...
...has a plain prompt, whereas the following has an asterik prepended
to the prompt:
Here's how it works. First, add this to your faces config file:
...
Some replacements for the standard
renderers
Replacement renderer for
h:outputLabel
javax.faces.Output
javax.faces.Label
renderers.LabelRenderer
Because we didn't specify a renderkit name, JSF modifies the default
renderkit by replacing the javax.faces.Label type renderer with our
custom version.
Here's the renderer class:
package renderers;
import java.util.Map;
import javax.faces.component.UIComponent;
import javax.faces.component.UIInput;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.Renderer;
// Renderer for the Label components
public class LabelRenderer extends Renderer {
public boolean getRendersChildren() {
return false;
}
public void encodeBegin(FacesContext context, UIComponent component)
throws java.io.IOException {
ResponseWriter writer = context.getResponseWriter();
writer.startElement("label", component);
String styleClass = (String)
component.getAttributes().get("styleClass");
if (styleClass != null)
writer.writeAttribute("class", styleClass, null);
Map attrs = component.getAttributes();
writer.writeAttribute("for", component.getClientId(context),
null);
UIInput input =
(UIInput)component.findComponent((String)attrs.get("for"));
if(input.isRequired())
writer.write("*");
writer.write(attrs.get("value").toString());
}
public void encodeEnd(FacesContext context, UIComponent component)
throws java.io.IOException {
ResponseWriter writer = context.getResponseWriter();
writer.endElement("label");
}
}
What's cool about this is that all h:outputLabel tags will be fitted
with our custom renderer, so by modifying the config file and
implementing the renderer, we are changing the behavior of existing JSP
pages without modifying the pages themselves. All labels that decorate
required fields will be prepended with asteriks.
Notice that my simple renderer is not industrial strength. It does not
account for all the h:outputLabel attributes, nor does it allow a
nested component. But it's not too bad for 20 minutes of work.
btw, it's easy to add an enhancement so that the asterik is red if the
corresponding field failed validation. Here's the modified encodeBegin
method of the renderer:
...
public void encodeBegin(FacesContext context, UIComponent component)
throws java.io.IOException {
ResponseWriter writer = context.getResponseWriter();
writer.startElement("label", component);
String styleClass = (String)
component.getAttributes().get("styleClass");
if (styleClass != null)
writer.writeAttribute("class", styleClass, null);
Map attrs = component.getAttributes();
writer.writeAttribute("for", component.getClientId(context),
null);
UIInput input =
(UIInput)component.findComponent((String)attrs.get("for"));
if(input.isRequired()) {
boolean msgs = hasMessages(context, input);
Re: pass bean as parameter to JSP
Le Dec 10, 2004, à 12:48 AM, Matthias Wessendorf a écrit : maybe it is not good JSF-Style but it definitely works! Of course you'll have to set the reference of "myVar" to managed JSF-Bean like this (if you don't do this, it will not work): yes, I would say, this is not good JSF-Style... There's nothing wrong with accessing JSF managed beans with JSTL tags. Managed beans differ from "regular beans" only in the manner in which they are constructed and initialized; otherwise, they are simply scoped variables. As Matthias points out below, you cannot use JSF html tags inside of c:forEach. That's not only bad style, but it won't work as you expect, at least until JSF 1.2. david geary Btw. looked at Oracle's ADF Faces? will enable you to do things like this in *good old* jsf-manner :) myVarAsManagedBeanDefinedInFacesConfig ClassOfMyVar myScope works without any problems :-) Regards, Hendrik Am Freitag, 10. Dezember 2004 07:38 schrieb Matthias Wessendorf: Hendrik, Heath means that you can't do things like: ... Hans Bergsten wroten a nice article on that (and other things): http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html Regards, Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 7:24 AM To: MyFaces Discussion Subject: Re: pass bean as parameter to JSP Am Donnerstag, 9. Dezember 2004 22:40 schrieb Heath Borders: I don't think you can use JSF tags inside a JSTL forEach tag. A managed bean specified in the faces-config is - afaik - a more or less normal jsp bean, reachable for all JSTL Tags, therefore you can do this (let's say myComp is a managed bean, specified in the faces-config): If you're instancing objects with the c:forEach-Tag and want to use one of them as a managed bean (to do value binding etc.) you'll need to set reference correct: Mabe it is not 100% standard conformable but belive me it works - I'm doing exactly this in my project with your MyFaces without having any troubles. Greetings, Hendrik
Re: JSF and Hibernate
The more interesting question is: do JSF and Spring work well together? If you're using Hibernate then you'll want Spring to make Hibernate more palatable. JSF and Spring are fully integrated thanks to the jsf-spring project on sourceforge. See https://sourceforge.net/projects/jsf-spring/ david Le Dec 14, 2004, à 8:59 AM, Hendrik Neumann a écrit : Yes, I do - but only since two days. Till now I didn't recognize any troubles, but I think that Hibernate and JSF "don't touch each other". Therefore I wouldn't lead back troubles to the combination of Hibernate and JSF. Am Dienstag, 14. Dezember 2004 15:16 schrieb mfaine: Anyone using JSF with Hibernate? Do they work well together? What has been your experience? -Mark
Re: practical difference between 'backingbean' and bean
Backing beans, as defined in Core JSF, are beans that maintain references to components in a page. As we point out in the book, sometimes it's necessary to do that; for example, to validate multiple fields at once in a page. As a general rule, you should use backing beans sparingly because it ties your beans to your components. david geary Le Dec 10, 2004, à 9:11 AM, mfaine a écrit : I'm reading Core JavaServer Faces by David Geary and Cay Horstmann. The authors sugest using backing beans rarely if ever and when I asked Mr. Horstmann about it I was never able to get a clear answer to this question: Isn't the difference academic?. I can't see how you can write a complete JSP site without mixing some presentation and business logic. Could anyone explain to me how this is possible? Thanks, -Mark
Re: pass bean as parameter to JSP
Le Dec 10, 2004, à 9:42 AM, Matthias Wessendorf a écrit : David, As Matthias points out below, you cannot use JSF html tags inside of c:forEach. That's not only bad style, but it won't work as you expect, at least until JSF 1.2. I guess you are inside of JCP-JSF-Group, isn't it? So my question: -JSF 1.2 will be included into J2EE 1.5 (aka J2EE 5)? I don't know when JSF 1.2 will be ready, but containers that support J2EE 1.5 must supply a JSF implementation. david thanks, Matthias david geary Btw. looked at Oracle's ADF Faces? will enable you to do things like this in *good old* jsf-manner :) var="myVarAsManagedBeanDefinedInFacesConfig" scope="myScope" /> myVarAsManagedBeanDefinedInFacesConfig ClassOfMyVar myScope works without any problems :-) Regards, Hendrik Am Freitag, 10. Dezember 2004 07:38 schrieb Matthias Wessendorf: Hendrik, Heath means that you can't do things like: ... Hans Bergsten wroten a nice article on that (and other things): http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html Regards, Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 7:24 AM To: MyFaces Discussion Subject: Re: pass bean as parameter to JSP Am Donnerstag, 9. Dezember 2004 22:40 schrieb Heath Borders: I don't think you can use JSF tags inside a JSTL forEach tag. A managed bean specified in the faces-config is - afaik - a more or less normal jsp bean, reachable for all JSTL Tags, therefore you can do this (let's say myComp is a managed bean, specified in the faces-config): If you're instancing objects with the c:forEach-Tag and want to use one of them as a managed bean (to do value binding etc.) you'll need to set reference correct: Mabe it is not 100% standard conformable but belive me it works - I'm doing exactly this in my project with your MyFaces without having any troubles. Greetings, Hendrik
Re: MyFaces / Tiles / Sitemesh
Le Mar 4, 2005, à 11:43 AM, Fadil a écrit :
Hi all,
Is it simple to integrate tiles with myfaces ?
Yes. In fact, it's already integrated. See the MyFaces website for more
details.
Works MyFaces bester with Sitemesh ?
I use both Tiles and SiteMesh with the JSF Reference Implementation and
I've had no difficulties with either. I'm sure the same is true for
MyFaces.
david
Toughts ?
On Fri, 04 Mar 2005 18:32:13 +, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
We're not actually using the MyFaces configurator to read the
elements
from the file. I don't think the MyFaces configurator even reads
them. I wrote my own digester to parse just those files. I'm just
using the existing elements so I dont' have to write my own DTD.
..
..
That way, you can just write , but the HtmlPanelGrid
that is returned has its columns attribute set to 1. This way, you
don't explicitly have to define the columns attribute, and we quit
getting those warnings about it being undefined.
This sounds like a similar solution proposed in Shale.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33752
A single subview tag is used to add to the existing component tree.
The subview is defined in XML configuration files. These files hold
reusable compositions of view metadata used to construct the sub
component tree. The XML structure provides a way to define a complex
component, say an address, and have the ability to extend and
override or add additional components.
Another example is a data table that defines columns for first and
last name. This component definition is extended adding an ssn and a
birthdate.
Another feature is that there is a substitution of the expression
language when constructing the components. This allows a view
fragment to be bound to more than one logical managed bean. For
example, in the dataTable defined above, #{managed-bean-name.persons}
might be substitued with #{personsTableEx.persons}. The substitued
name would be defined by the suviews id attribute.
Gary
Re: MyFaces / Tiles / Sitemesh
Le Mar 4, 2005, à 4:23 PM, [EMAIL PROTECTED] a écrit : I've been poking around the new subview stuff Craig has added to Shale. Do you know if it supports Tiles yet? I seem to recall that is in Craig's long range plan... (Documentation is obviously a little sketchy at this point) I know that tiles support is something that he plans to include because the mentioned that when I approached him about my subview ideas. I don't think that he has committed yet if it's done. He indicated that hes been consumed. Support for Tiles is definitely a goal for Shale. What form that will ultimately take hasn't been decided yet. Realize that you don't need Shale Tile support to use Tiles with JSF. All you have to do is wrap tile inserts in subviews, like this: ... Make sure you provide an id attribute for your subview. The convention is to name the subview the same as the tile (or tile attribute) that you're inserting. Other than the subview thing, you use Tiles exactly as you would without JSF, although content for your tiles will typically contain JSF components. As for layouts, I like to keep my layouts free of JSF components so I can use them with plain JSP, Struts, Faces, etc. david Gary sean Gary, I've been poking around the new subview stuff Craig has added to Shale. Do you know if it supports Tiles yet? I seem to recall that is in Craig's long range plan... (Documentation is obviously a little sketchy at this point) sean On Fri, 04 Mar 2005 20:11:14 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi all, Is it simple to integrate tiles with myfaces ? Works MyFaces bester with Sitemesh ? Toughts ? This is could be kind of an interesting option. I'm not sure if this is the vision that you are seeing but I suppose that a subcomponent tree could be constructed for an XHTML fragment? What if you where able to wrapper the request and response and a context object and then perform an HTTP "include" to a Sitemesh template. Then take the data in the wrapper response and use it to add on to the component tree. Maybe an adaptor could be snapped in to support different types of defining documents (XHTML, XML, HTML). I think you would loose allot of what faces has to offer if you didn't provide a way to register listeners taking advantage of the full lifecycle. Gary
Re: [OT] JSF2.0 and AJAX
Le Mar 11, 2005, à 2:45 PM, Jonathan Eric Miller a écrit : Thanks for the links. Those Google links are cool. I wonder how long off JSF 2.0 is, or, even 1.2 for that matter... I hope we don't have to wait years for JSF standard file upload and other components. I bet 2.0 will be a long time coming, but it doesn't matter. In the meantime there will be plenty of choices. Shale, for one, will scratch these itches. JSF is hot. AJAX is hot. Never fear. david Jon - Original Message - From: "Matthias Wessendorf" <[EMAIL PROTECTED]> To: "MyFaces-User" Sent: Friday, March 11, 2005 2:47 PM Subject: [OT] JSF2.0 and AJAX Hi all, just surfed a bit the web and saw that JSF resource: https://javaserverfaces.dev.java.net/presentations/20050305-tssjs.pdf If you want more on AJAX look here: http://www.adaptivepath.com/publications/essays/archives/000385.php Nice evening, Matthias
Re: Strange navigation in MyFaces examples
I'm using Shale in a commercial application. I haven't encountered any bugs, so it's stable enough for me. david Le Mar 14, 2005, à 11:56 AM, Craig McClanahan a écrit : On Mon, 14 Mar 2005 19:30:50 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: P.S. @Craig: Is it possible/reasonable to use StrutsShale already, since there are no stable builds so far? It is *possible* to use Shale already -- indeed, I would appreciate it if people would try this out and provide feedback. You can get to nightly builds from the links on: http://wiki.apache.org/struts/StrutsShale There is no formal EA build yet (although such a build would have no different real life quality than an arbitrary nightly build). Just be aware that the APIs for Shale are still under development, and subject to change. That's particularly true with the "DialogController" stuff. I'm not anticipating that ViewController will change much unless user feedback indicates that there are usability problems that need to be addressed. Craig
Re: Shale in commercial application (was RE: Strange navigation in MyFaces examples)
Le Mar 15, 2005, à 9:26 AM, Korhonen, Kalle a écrit : If I may ask, is your commercial application released yet? If not, what's you target timeframe? No, it's not released yet. It will probably be released sometime in April. david Kalle -Original Message----- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 12:33 AM To: MyFaces Discussion Subject: Re: Strange navigation in MyFaces examples I'm using Shale in a commercial application. I haven't encountered any bugs, so it's stable enough for me. david Le Mar 14, 2005, à 11:56 AM, Craig McClanahan a écrit : On Mon, 14 Mar 2005 19:30:50 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: P.S. @Craig: Is it possible/reasonable to use StrutsShale already, since there are no stable builds so far? It is *possible* to use Shale already -- indeed, I would appreciate it if people would try this out and provide feedback. You can get to nightly builds from the links on: http://wiki.apache.org/struts/StrutsShale There is no formal EA build yet (although such a build would have no different real life quality than an arbitrary nightly build). Just be aware that the APIs for Shale are still under development, and subject to change. That's particularly true with the "DialogController" stuff. I'm not anticipating that ViewController will change much unless user feedback indicates that there are usability problems that need to be addressed. Craig
Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
This begs the question of why MyFaces components aren't a project of their own. An FAQ on this mailing list is whether the MyFaces components will work with the RI, so there's some confusion as to why MyFaces has components that aren't MyFaces-specific. Perhaps Shale should absorb the MyFaces components. 8-) david Le Mar 15, 2005, à 11:32 AM, Craig McClanahan a écrit : On Tue, 15 Mar 2005 13:43:08 +0100, Matthias Wessendorf [snip] Fine! Working together should be the best JSF user could get, independent from which Impl of JSF Spec they might use. Absolutely. It is very important, that Shale works with MyFaces (it does, I am "playing" with both during learning Shale ;)) Shale tries to make zero non-spec assumptions about the underlying implementation, so working with both MyFaces and the RI will keep me honest too :-). Also MyFaces' extra components should work with Shale; haven't looked at the remote thing in Shale. "Only" looked in "ViewController" and I am fascinated about that! But session scoped "DialogController" seams also to be very usefull. Word of caution -- DialogController is likely to be undergoing some revisions. As you also pointed out, that we are discussing the subproject issue, does it make sense for you, to host Shale at MyFaces? If the scope of MyFaces had been "We want to create a JSF spec-compliant implementation, *and* we want to build other things that depend on JSF" it might be a good fit. Since the scope actually seems to be "We want to create a JSF spec-compliant implementation, and oh by the way here are some cool components" that wasn't as good a fit as Struts, where the mission is to create a web app framework. For now, Shale got accepted as a Struts sub-project. Whether it stays there, or migrates here, or graduates to its own status in the future -- that's going to depend on what actually happens. In the mean time, we can work together on value adds, and figure out how to share as we go. Shale should be build on top of JSF API, like our components. Yep. Since Shale is a framework that tries to leverages JSF, I see some "overlap" in MyFaces' custom components and Shale (and its components). Also both "teams" will have some util classes, that do the same stuff for providing helper methods, independent from a specific implementation. see: http://tinyurl.com/4zhd7 Although, as I remarked in reponse to this particular post, I'm tired of getting burned by implementing static helper classes :-). But your point is well taken. Where does one create components that have Shale dependencies, for example? or the mentioned "client side validation" or "file upload component" for instance. It's going to be interesting to work these things out. -Matthias Craig
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
It would be great to have one-stop shopping of sorts for Apache projects related to JSF. I like grouping JSF-related projects and decoupling unrelated pieces at the same time. Apache Portals looks like a good candidate to emulate. david Le Mar 15, 2005, à 1:55 PM, Matthias Wessendorf a écrit : David, I am just about to answer Craig regarding his post... But you said it very very clear to something I just thought... So here is my post... Take a look at Apache Portals, that is something I have in mind on *long term* There could be a similar Toplevel Project btw. name it "Apache Faces". One of the subprojects could be MyFaces, since it is a implementation of the Faces Spec. Another could subprojects could contain only custom components Another could host some sample apps that explain the "usage" of Faces (with and without the custom components) And also Shale could be a subproject of that Apache Faces project, since Shale is a (cool) framework that leverages JSF. Let me come back to Portals, they host pluto (portlet impl. (yes RI)) and some usages like remote portals and Jetspeed portal stuff. So why not "copy" that what strutcture, since it was/is good for Portlet technology, for the JavaServer Faces technology ? BTW. I hope it's not to radical ;) -Matthias David Geary wrote: This begs the question of why MyFaces components aren't a project of their own. An FAQ on this mailing list is whether the MyFaces components will work with the RI, so there's some confusion as to why MyFaces has components that aren't MyFaces-specific. Perhaps Shale should absorb the MyFaces components. 8-) david Le Mar 15, 2005, à 11:32 AM, Craig McClanahan a écrit : On Tue, 15 Mar 2005 13:43:08 +0100, Matthias Wessendorf [snip] Fine! Working together should be the best JSF user could get, independent from which Impl of JSF Spec they might use. Absolutely. It is very important, that Shale works with MyFaces (it does, I am "playing" with both during learning Shale ;)) Shale tries to make zero non-spec assumptions about the underlying implementation, so working with both MyFaces and the RI will keep me honest too :-). Also MyFaces' extra components should work with Shale; haven't looked at the remote thing in Shale. "Only" looked in "ViewController" and I am fascinated about that! But session scoped "DialogController" seams also to be very usefull. Word of caution -- DialogController is likely to be undergoing some revisions. As you also pointed out, that we are discussing the subproject issue, does it make sense for you, to host Shale at MyFaces? If the scope of MyFaces had been "We want to create a JSF spec-compliant implementation, *and* we want to build other things that depend on JSF" it might be a good fit. Since the scope actually seems to be "We want to create a JSF spec-compliant implementation, and oh by the way here are some cool components" that wasn't as good a fit as Struts, where the mission is to create a web app framework. For now, Shale got accepted as a Struts sub-project. Whether it stays there, or migrates here, or graduates to its own status in the future -- that's going to depend on what actually happens. In the mean time, we can work together on value adds, and figure out how to share as we go. Shale should be build on top of JSF API, like our components. Yep. Since Shale is a framework that tries to leverages JSF, I see some "overlap" in MyFaces' custom components and Shale (and its components). Also both "teams" will have some util classes, that do the same stuff for providing helper methods, independent from a specific implementation. see: http://tinyurl.com/4zhd7 Although, as I remarked in reponse to this particular post, I'm tired of getting burned by implementing static helper classes :-). But your point is well taken. Where does one create components that have Shale dependencies, for example? or the mentioned "client side validation" or "file upload component" for instance. It's going to be interesting to work these things out. -Matthias Craig -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
I prefer Matthias' proposal for Apache Faces. I think it'd be great to have all JSF-related technologies in one project. As for the Faces components, as long as they're MyFaces components, people will be confused about using them standalone. We can add documentation, but people will still be confused. The only way to eliminate the confusion is to put them in a separate project. I think the components will thrive independent of MyFaces. The JSF community needs a good open-source component set independent of a particular JSF implementation and I feel like we're hiding one inside MyFaces at the moment. Finally, I don't think Shale should be part of MyFaces. If Shale is absorbed with MyFaces, we'll have exactly the same problem that we have with the components: people will wonder if they can use Shale with other JSF implementations. A certain percentage will eschew Shale (and the components) because they will assume they're MyFaces specific and never take the time to investigate, or read the documentation. IMO, MyFaces should strictly adhere to providing a robust JSF implementation. Some extensions that are tied to the framework, such as Tiles support, are fine, but adding things to MyFaces that have nothing to do with MyFaces, per se, invites confusion and limits the adoption of those technologies. david Le Mar 16, 2005, à 12:30 PM, Sean Schofield a écrit : I agree 100% with Martin on this one. On one of these threads Kito made a comment about people being confused about the myfaces components and whether or not they require myfaces. We should do our best to promote the fact that the components are independent of the implementation. Improvements to our documentation will help with that. There is a place holder "overview" page on the myfaces site where just such documentation should go. I will add some shortly. sean On Wed, 16 Mar 2005 20:18:23 +0100, Martin Marinschek <[EMAIL PROTECTED]> wrote: I am replying to several postings on the mailing list in the last time at once, so sorry if I puzzle someone. With all this discussion on toplevel or sublevel or whatever level projects we should still try to get our infrastructure up-to-date first (I agree with Matthias and his former postings on this topic). In the last one and a half years, we have had (4) different homepages, we should finally try to get the dust cloud to settle down. For the meantime, I believe that all is quite good as it is right now, even with the components being part of MyFaces. The thing is that it is much easier to work on the components if they are at least part of the common source base of the framework, and this might be a reason why the components of MyFaces are indeed thriving as much as they do. As soon as we get to be a large bureaucratic body, we should stop, rethink our ways and move the components out to a subproject. regards, Martin On Wed, 16 Mar 2005 13:16:53 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <[EMAIL PROTECTED]> wrote: Personally, I'm not convinced that Shale really should be part of the MyFaces project. If you look at JSF as a foundation for UI frameworks (and more sophisticated web frameworks in general), then hopefully we'll see it pop up in lots of different places (in my perfect world, even Tapestry would use JSF components). Placing all projects that use JSF under one umbrella may break over time as JSF grows. (For example, all Java projects are no longer part of Jakarta.) Good point. We definitely don't want to rush into something like this. There are potential drawbacks as you pointed out. Moreover, although Shale is based on JSF, it will hopefully be the next major revision of Struts. Struts has its own very strong brand, and it seems strange to pull Shale away from that. That is a big question mark but I happen to agree with you (and Craig) on the desirability of that outcome. Moving Shale to a new project does pretty much give up on that idea so I can see that as a drawback. sean
Re: [OT] Shale @ JavaOne
Le Mar 20, 2005, à 5:33 AM, Matthias Wessendorf a écrit : Cool to see, that David Geary's proposal was accepted. He speaks about Shale at JavaOne. (see [1]) Thanks. Unfortunately Bill Dudney and I got a message, that our talk about Apache MyFaces wasn't accepted for JavaOne :-( Sorry to hear that. I hope there is some coverage of MyFaces at JavaOne. If it helps any, I have decided to add a MyFaces session to my NFJS agenda, starting sometime in late April. But, perhaps the talk from Martin and me @ApacheCon Europe in Germany / Stuttgart gets accepted ;) What about Javaoplis? I would love to do a MyFaces or Shale talk there. david -Matthias [1] http://www.jroller.com/page/dgeary/20050319#shale_the_next_struts_at
Re: Are there any plans for a JSF 1.2 book?
Le Apr 18, 2005, à 3:45 PM, Sean Schofield a écrit : Obviously the spec is not done yet but I'd be curious if any of the JSF authors are thinking about an updated book covering the 1.2 spec? Bill? Kito? David? Hans? Cay and I will update Core JSF for 1.2. david sean
Re: Are there any plans for a JSF 1.2 book?
Le May 26, 2005 à 9:18 AM, IdRatherBeSailing a écrit : --- Sean Schofield <[EMAIL PROTECTED]> wrote: But Shale is a new framework that's not yet done and it has now embedded these useful-across-the-JSF-board tags within the Shale Core such that you couldn't use them without including the Shale core in your app. Struts didn't include commons-validator within Struts core, it's a separate subproject so that it could be used across other projects that had similar needs. The assumption that underlies this argument--that Shale is a framework like Struts--is misguided. With Struts, you buy into a mindeset and, like other Struts users, you implement a Struts application, complete with actions, forms, etc. Shale is different because it's a collection of decoupled services that sits on top of any JSF implementation. You can use any feature (web flow, validation, Spring or Tiles integration, tokens, JNDI access) without using any of the others. Shale is one-stop shopping for those things you wish JSF had. The only framework you buy into when you use Shale is JSF. Regardless of whether you use MyFaces, the RI, or Joe's JSF, take what goodies you like from Shale and be done with it. david
Re: Are there any plans for a JSF 1.2 book?
Le May 26, 2005 à 12:44 PM, Sean Schofield a écrit : Btw. Sean, is there a place with a good introduction about Shale, mainly the components and what is being worked on? I checked the shale site a while ago and could not find anything except a few comments and a rather vague description. Just the wiki http://wiki.apache.org/struts/StrutsShale The javadoc actually contains quite a bit of explanation. The usescases are also built nightly and they are an excellent example of how the new dialog stuff works. I posted a blog entry on Shale Web Flow the other day. See /http:// jroller.com/page/dgeary david
Re: Are there any plans for a JSF 1.2 book?
Le May 26, 2005 à 2:53 PM, IdRatherBeSailing a écrit : Ok I give up, my point (wanting just the tag without the overhead of the pieces I don't want) obviously isn't getting across, so I'll either have to end up including all of the shale core in my webapps or use some of shale source and not others and build the pieces myself or implement my own tag against commons-validator (haven't looked to see if the tags from David's book are under an apache-equivalent license or not)... There are no restrictions regarding the use of the book's tags. One question though, if I did try to use it against the Shale core jar (using just the validation tag and no other parts of the Shale core (yet)), isn't there a faces-config.xml in the Shale core jar that will end up configuring JSF extensions (and thus overhead like view/navigation handlers/wrappers?) that I won't be using and don't necessarily want taking up resources for no good reason (in apps that just want to use straight JSF for now)?... Yes, Shale will install some mean mothers. If they prove to be a performance bottleneck in your application then you're a hell of an architect. 8-) david If anybody else knows of JSF tag(s) for general commons-validator use besides David's book and Shale, that I should be evaluating (vs writing my own) please let me/us know... __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Are there any plans for a JSF 1.2 book?
Le May 26, 2005 à 3:24 PM, IdRatherBeSailing a écrit : Thanks for the clarification on the licensing (or lack thereof) of the tags from the book... Yes, Shale will install some mean mothers. If they prove to be a performance bottleneck in your application then you're a hell of an architect. 8-) I was more worried about bugs and perception (what new fangled thang are you putting in my app and why?) than performance, but your sarcasm is welcome anyway :-)... It does clarify that you may end up getting more than you asked for if you think you're just using one tag from the core and not the rest of shale (due to config in the core jar pulling in stuff you didn't ask for). Like you said, probably not the biggest performance issue you'll run into, but still good to know what it's doing without you asking it to, to help in deciding whether to use just the tag from Shale or to stick with the standalone tag(s) from the book. Yes. The upside to the Shale tags, of course, is that they'll be maintained. You'll have to do that yourself for the book's tags. Either way, it's nice to have robust validation at your fingertips. david __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Re: Are there any plans for a JSF 1.2 book?
Hi Duong,
Please repost this on the Struts dev mailing list, with a prefix of
[Shale]. We're taking up too much MyFaces bandwidth on this.
Thanks,
david
Le May 26, 2005 à 4:58 PM, Duong BaTien a écrit :
On Thu, 2005-05-26 at 14:45 -0600, David Geary wrote:
Le May 26, 2005 à 12:44 PM, Sean Schofield a écrit :
Btw. Sean, is there a place with a good introduction
about Shale, mainly the components and what is being worked on?
I checked the shale site a while ago and could not find anything
except a few comments and a rather vague description.
Just the wiki
http://wiki.apache.org/struts/StrutsShale
The javadoc actually contains quite a bit of explanation. The
usescases are also built nightly and they are an excellent
example of
how the new dialog stuff works.
I posted a blog entry on Shale Web Flow the other day. See /http://
jroller.com/page/dgeary
david
Hello David:
I manage to get back to Shale Dialog and read you blog on Shale Web
Flow. Craig just comes back from vacation. So i decide to fire up some
of the questions. Hope you two may save me time to dig around.
1) You said Shale loads the state's view using the supplied viewId
(which i am able to replace my previous implementation under
DialogController to the new Dialog), and soon we will be able to
supply
a tile based on your work. I wonder what is its implication?
2) If i recalled in the previous version of DialogController, Craig
said
"soon" we will be able to have different instances of
DialogController,
controlling different fragments (tiles) in the same page, so the
deprecated DialogController is similar to Tiles controller but it can
last more than a request. I look at the new Dialog Status and
StatusImpl, there is only 1 property data. Hence, at any point you can
only associate 1 state to the {dialog.data}. I wonder how different
work
flows can be independently associated to different fragments in the
same
page? Specifically, i am thinking different workflows are associated
with different applications; each application occupies a fragment of a
portal page.
Thanks.
BaTien
DBGROUPS
