SV: [ANNOUNCE] New Shale PMC Chair
Congratulations, Gary - Keep up the good work for the community. Hermod -Opprinnelig melding- Fra: Greg Reddin [mailto:[EMAIL PROTECTED] Sendt: 20. mars 2008 15:41 Til: [EMAIL PROTECTED]; dev@shale.apache.org Emne: [ANNOUNCE] New Shale PMC Chair In its meeting yesterday the Apache Board of Directors unanimously approved a resolution naming Gary VanMatre the new chair of the Apache Shale Project Management Committee. Please join us in congratulating Gary for this new role. In addition we would like to publicly thank Craig McClanahan for his service to this project and his invaluable contribution to the Java web application development community. We are endlessly grateful to him for his role in defining the JavaServer Faces framework and, more specifically, in birthing the Shale project. It is no small loss to this community that his work has made it difficult for him to be as involved as he once was. At his own request, Craig is now an emeritus member of the Shale PMC. Thank you, Greg Reddin Apache Shale PMC Member
SV: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution
Hi Been away for quite a while, but back again. +1 Hermod -Opprinnelig melding- Fra: Wendy Smoak [mailto:[EMAIL PROTECTED] Sendt: 12. juli 2007 02:27 Til: dev@shale.apache.org Emne: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution This is a vote to accept Ryan Wynn's contribution of the Shale Clay Plugin for Eclipse, which can be found attached to the SHALE-444 JIRA ticket. * https://issues.apache.org/struts/browse/SHALE-444 The IP Clearance form will be committed to the Incubator site shortly, and I'll link this thread to show our acceptance. Please be reminded that contributors are responsible for ensuring that a Corporate CLA is recorded if such is required to authorize their contributions under their individual CLA. [ ] +1 - Let's accept the contribution [ ] -1 - We should not accept it because... -- Wendy Smoak
SV: SV: SV: Submitted values lost - view is refilled everytimewithmodel values
Hi Most likely - I am not the one who entered it. We need to take a closer look at it. Hermod -Opprinnelig melding- Fra: Torsten Krah [mailto:[EMAIL PROTECTED] Sendt: 27. april 2007 16:10 Til: [EMAIL PROTECTED] Emne: Re: SV: SV: Submitted values lost - view is refilled everytimewithmodel values Shouldn't this be a bug instead of an improvement than, should it? Torsten Am Freitag, den 27.04.2007, 12:19 +0200 schrieb Hermod Opstvedt: Hi If the loop removes all request values from scope prior to rendering, and then applies the persisted state? Hermod -Opprinnelig melding- Fra: Torsten Krah [mailto:[EMAIL PROTECTED] Sendt: 27. april 2007 10:18 Til: [EMAIL PROTECTED] Kopi: [EMAIL PROTECTED] Emne: Re: SV: Submitted values lost - view is refilled everytime withmodel values Hm read 410 issue but don't see the connection yet, can you be a bit more detailed about it? Torsten Am Donnerstag, den 26.04.2007, 21:46 +0200 schrieb Hermod Opstvedt: Hi I think this is related to [1], since you are missing stuff from scope [1] https://issues.apache.org/struts/browse/SHALE-410 Hermod -Opprinnelig melding- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 26. april 2007 17:51 Til: [EMAIL PROTECTED] Emne: Re: Submitted values lost - view is refilled everytime with model values Got a problem with clay and flowScoped Spring beans. My view is everytime filled with the model values. The submitted values are lost. I can enter some data in my input fields and submit the form - if i left some required input fields empty, a message appears that something is missing, so far so good. However, the same field which i left empty - and all others i may have changed - are now populated again with values from my bean. What might cause this? I thought the component should remember this value and display this instead of the beans model value. Lifecycle stopped processing at Validation phase, so the components should not be cleared, any idea or tipps to debug this? I took a look at the webflow javadoc [1]. It looks like they are using a couple tricks for saving the FlowExecution. The FlowPhase listener [2] adds a non-visual component to the view root to keep state. It also adds the flow execution key to the view root.It looks like the flow key is used to restore the FlowExecution. I suspect the problem you are seeing has to do with the state not being resorted for the current flow on the postback. I would try setting some break points in the FlowPhaseListener. [1] http://static.springframework.org/spring-webflow/docs/current/api/overview-s ummary.html [2] http://opensource.atlassian.com/projects/spring/secure/attachment/12520/Flow ExecutionKeyStateHolder.patch Torsten Gary
SV: [jira] Commented: (SHALE-402) clay xml bindings for ibm jsf components
Hei Place them in the WEB-INF directory, or wherever you like. You will need to add them to the follow section in web.xml !-- Clay Common Configuration Resources -- context-param param-name org.apache.shale.clay.COMMON_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml, . /WEB-INF/ibm-jsf.xml --- Whatever you call it and where ever you place it /param-value /context-param Hermod -Opprinnelig melding- Fra: Apurva Mistry (JIRA) [mailto:[EMAIL PROTECTED] Sendt: 11. april 2007 20:15 Til: issues@shale.apache.org Emne: [jira] Commented: (SHALE-402) clay xml bindings for ibm jsf components [ https://issues.apache.org/struts/browse/SHALE-402?page=com.atlassian.jira.pl ugin.system.issuetabpanels:comment-tabpanel#action_40777 ] Apurva Mistry commented on SHALE-402: - Where to place these xml files in RAD. Also can I use clay for developing portlets. Thanks clay xml bindings for ibm jsf components Key: SHALE-402 URL: https://issues.apache.org/struts/browse/SHALE-402 Project: Shale Issue Type: New Feature Components: Clay Affects Versions: 1.0.4 Environment: All Reporter: Ryan Wynn Priority: Minor Attachments: html_extended-2.0-config.xml, ibm-config.xml Clay bindings for ibm jsf components. Much like the tomahawk bindings this xml file allows clay to weave ibm's extended component library (jsf-ibm.jar) into the view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SV: JSCoockMenu, hidden inputs and name attribute
Hi See comment inline bwlow -Opprinnelig melding- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 27. mars 2007 17:51 Til: dev@shale.apache.org Emne: Re: JSCoockMenu, hidden inputs and name attribute From: [EMAIL PROTECTED] Hi In my quest for better samples and documentation, I have started creating sample Clay configurations for the variuos Tomahawk components. I have run into an issue that has made me scratch my head a bit. First there is an issue[1], [2] with the Tomahawk JSCoockMenu and the inner form. There is a workaround for this that can be achieved if you code the menu in Clay-HTML style as outlined in [2]. You mean something like this: span jsfid=ignore input type=hidden name=jscook_action / /span Now trying to achieve the same in XML is however not that easy. The reason being that you can not set the name attribute of the inputHidden component in such a way that is does not get mangled with an id. in front of it when it gets rendered. I see what you mean. A JSF inputSecret would behave like any other component. I have a couple ideas to try. We could try using the clayOut to generate makup that is ignored by the html to component mappings. component jsfid=t:jscookHidden extends=clayOut attributes set name=escapeXml value=false/ set name=value value=lt;input type=quot;hiddenquot; name=quot;jscook_actionquot; /gt;/ /attributes /component Another option might be to use the tomahawk t:inputSecret. It has a forceId option that ignores naming containers. component jsfid=t:jscookHidden extends=t:inputSecret id=jscook_action attributes set name=forceId value=true/ /attributes /component This leads me to wonder: Does the name attribute have to follow the naming scheme of the id's? As far as I can tell it is not need when building/restoring the component tree, so it should be possible to set it to some name and have its name remain untouched. If is has not been specified, then the renderer is free to do what ever it wants. I have noticed that the only components that get a name rendered by default are forms and hidden inputs. For the form I can see why one needs a name attribute, but not for the hidden inputs. I think it becomes an issue if you are using the same component by id within the same naming container. But, I think that there are several efforts to solve the problem. The Trinidad tr:form component is not a naming container. This means that the components added to the trinidad form component will not be prefixed with the form name. The tomahawk components have the forceId. I want to say that JSF 1.2 has something similar but I might be making that up. I am not referring to the id, but to the name. I ail to see why that has to go into the componenttree idenitifaction scheme. I don't think this is something that Clay can solve. It's the components responsibility to render markup. Clay only glues them together. I propose that we in Clay add the ability so set the name as an attribute, and have it retain that value unchanged. IMO, unless we can find another scenario, I'd rather not make changes just to make this one component work. The component should be renderering the hidden attribute if it is needed by the component. As you can see from a later mail, it's been fixed in tomahawk 1.1.6-SNAPSHOT, so I'm happy with that Hermod Gary [1] http://issues.apache.org/jira/browse/MYFACES-219?page=com.atlassian.jira.plu gin. system.issuetabpanels:all-tabpanel [2] http://www.mail-archive.com/dev@myfaces.apache.org/msg20819.html Hermod * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SV: svn commit: r517688 - in /shale/framework/trunk: shale-application/ shale-apps/mailreader-jpa/ shale-apps/shale-blank/ shale-apps/shale-clay-usecases/ shale-apps/shale-mailreader-jpa/ shale-apps/s
Hi Points taken - I just forgot to add the issuenumber as a start to the comments. I'll take a look at the autoprops on TortoiseSVN. Hermod -Opprinnelig melding- Fra: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sendt: 15. mars 2007 16:14 Til: dev@shale.apache.org Emne: Re: svn commit: r517688 - in /shale/framework/trunk: shale-application/ shale-apps/mailreader-jpa/ shale-apps/shale-blank/ shale-apps/shale-clay-usecases/ shale-apps/shale-mailreader-jpa/ shale-apps/shale-mailreader/ shale-apps/shale-sql-browser/ sha On 3/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: hermod Date: Tue Mar 13 06:25:08 2007 New Revision: 517688 URL: http://svn.apache.org/viewvc?view=revrev=517688 Log: Added mising Tag handlers for validators and converters, and also updated the ignore list snip/ First of all, welcome -- glad to have you on-board and thanks for all your contributions to Shale (yes, I'm playing catchup with email :-). I have a few stylistic comments on this commit: * Please check your svn client for auto-props [1], the added files here don't seem to have props (particularly eol-style and keywords are what I care about). * AFAICT, at Shale we mark all commits against issues. This is particularly important with framework trunk (and other non-sandbox locations), IMO. * Usually better to stick to one purpose per commit (for example, here, adding the tag handlers and adding the svn:ignore bits would be well served in separate commits, again IMO). To humor the bullet above this one, then, we sometimes create catch-all issues (such as SHALE-310, which probably should have been closed at v1.0.4 release, but I digress). -Rahul [1] http://www.apache.org/dev/svn-eol-style.txt [2] http://issues.apache.org/struts/browse/SHALE-310 Added: shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/DoubleConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/DoubleValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/FloatConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/FloatValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/LongConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/LongValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/ShortConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validat or/tag/ShortValidatorTag.java Modified: shale/framework/trunk/shale-application/ (props changed) shale/framework/trunk/shale-apps/mailreader-jpa/ (props changed) shale/framework/trunk/shale-apps/shale-blank/ (props changed) shale/framework/trunk/shale-apps/shale-clay-usecases/ (props changed) shale/framework/trunk/shale-apps/shale-mailreader/ (props changed) shale/framework/trunk/shale-apps/shale-mailreader-jpa/ (props changed) shale/framework/trunk/shale-apps/shale-sql-browser/ (props changed) shale/framework/trunk/shale-apps/shale-test-tiger/ (props changed) shale/framework/trunk/shale-apps/shale-usecases/ (props changed) shale/framework/trunk/shale-clay/ (props changed) shale/framework/trunk/shale-core/ (props changed) shale/framework/trunk/shale-dialog/ (props changed) shale/framework/trunk/shale-dialog-basic/ (props changed) shale/framework/trunk/shale-dialog-scxml/ (props changed) shale/framework/trunk/shale-remoting/ (props changed) shale/framework/trunk/shale-spring/ (props changed) shale/framework/trunk/shale-test/ (props changed) shale/framework/trunk/shale-tiger/ (props changed) shale/framework/trunk/shale-tiles/ (props changed) shale/framework/trunk/shale-validator/ (props changed) shale/framework/trunk/shale-view/ (props changed) snap/
SV: [jira] Commented: (SHALE-425) ViewControllerMapper allows mapping only to one bean
Hi I think maybe there is a misunderstanding of idea behind the ViewController. It is exactly for mapping one Controller! against a view - Hence the name ViewController. Just out of curiosity: Why would you want multiple viewcontrollers against a view? I think you may have misunderstood something. You can use multiple beans! To feed a view with data. Hermod -Opprinnelig melding- Fra: Matthias Wuttke (JIRA) [mailto:[EMAIL PROTECTED] Sendt: 14. mars 2007 13:47 Til: issues@shale.apache.org Emne: [jira] Commented: (SHALE-425) ViewControllerMapper allows mapping only to one bean [ https://issues.apache.org/struts/browse/SHALE-425?page=com.atlassian.jira.pl ugin.system.issuetabpanels:comment-tabpanel#action_40550 ] Matthias Wuttke commented on SHALE-425: --- Another (IMHO good) mapping strategy would be to allow backing beans to programmatically register themselves with the view mapper: MyCoolDynamicViewMapper.registerBean(ctx.getViewRoot().getViewId(), myBeanName); This allows the use of abstract super classes for backing beans and allows for backing beans that are responsible for different views. ViewControllerMapper allows mapping only to one bean Key: SHALE-425 URL: https://issues.apache.org/struts/browse/SHALE-425 Project: Shale Issue Type: Improvement Components: View Affects Versions: 1.0.4 Reporter: Matthias Wuttke Priority: Minor ViewControllerMapper.mapViewId(String viewId) allows only to map a view to a single bean. A key feature of JSF (IMHO) is the ability to have multiple backing beans / view controllers that contribute to a single page. An extension of this interface could allow other mapping strategies to associate multiple beans with a given page that can then receive phase change events. A possiblte mapping strategy would be a XmlViewControllerMapper which takes a XML file that associates view ids with bean names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Tomcat 5.5.23
Hi
Downloaded and tested Tomcat 5.5.23 today with Java5, and it still has the
errors that where introduced post 5.5.17, meaning that you get the following
error during startup:
[16 2007-03-13
18:52:23,062](org.apache.catalina.core.ContainerBase.[Catalina].[localhost].
[/claycomp])**ERROR**{org.apache.catalina.core.ApplicationContext.log:676}
User: -StandardWrapper.Throwable
java.lang.IllegalStateException: No Factories configured for this
Application. This happens if the faces-initialization does not work at all -
make sure that you properly include all configuration settings necessary for
a basic faces application and that all the necessary libs are included. Also
check the logging output of your web application and your container for any
exceptions!
If you did that and find nothing, the mistake might be due to the fact that
you use some special web-containers which do not support registering
context-listeners via TLD files and a context listener is not setup in your
web.xml.
A typical config looks like this;
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/lis
tener-class
/listener
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:90)
snip/
Looks like it is not registering the listeners in the jar files anymore
after 5.5.17.
Has anybody heard anything about this (Apart from my previous rant)?
Hermod
JIRA Access
Hi It does not look like I have been granted rights to Jira yet. I would like to assign https://issues.apache.org/struts/browse/SHALE-391 to my self and then close it now that the Archetype has been promoted from the sandbox. Who do I contact to get the correct Jira permissions? Hermod
SV: JIRA Access
Hi Thanks Wendy - Looks Ok now. Hermod -Opprinnelig melding- Fra: Wendy Smoak [mailto:[EMAIL PROTECTED] Sendt: 11. mars 2007 20:21 Til: dev@shale.apache.org Emne: Re: JIRA Access On 3/11/07, Hermod Opstvedt [EMAIL PROTECTED] wrote: It does not look like I have been granted rights to Jira yet. I would like to assign https://issues.apache.org/struts/browse/SHALE-391 to my self and then close it now that the Archetype has been promoted from the sandbox. Who do I contact to get the correct Jira permissions? You have two accounts on JIRA. I added 'shale-developers' to the one matching your email address. Let me know if you're using a different account. -- Wendy
SV: [ANNOUNCEMENT] New Shale Committer: Hermod Opstvedt
Hi Thank you all. I'm very honoured and look forward to keep contributing to this exciting project, thereby hopefully bringing it even more forward. Hermod -Opprinnelig melding- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 10. mars 2007 02:55 Til: user@shale.apache.org; dev@shale.apache.org Emne: [ANNOUNCEMENT] New Shale Committer: Hermod Opstvedt Please join me in welcoming Hermod Opstvedt as a new Shale committer. Hermod has been a very active supporter of Shale over the past year. Besides speaking Norwegian and English, he also speaks Maven. His recent contributions includes the clay2tld tool with a maven plug-in and the new shale-clay-starter-archetype. Welcome aboard, Hermod! Gary
Promoting the ShaleClay starter archetype
Hi Since there was a unanimous vote for doing this, I will start on moving this into the trunk from the sandbox. Hermod
SV: Determining the flavor of the JSF runtime
Hi Reading the manifest depends on who build it, so that may break quickly I think a better approach is to create small utility that looks for the few (two?) implementations of a given class that has distinct characteristics for the different versions of the api. Hermod -Opprinnelig melding- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 6. mars 2007 17:16 Til: dev@shale.apache.org Emne: Determining the flavor of the JSF runtime I've been trying to determine a better strategy for detecting the supplier and version of the JSF runtime. This has to do with a open JIRA ticket [1]. I attempted to create a utility class to determine the implementor of the runtime and the JSF spec version [2]. This was a real hack but I didn't see a better way and I'm still not sure the best way to dynamically extract this version information. Besides knowing the JSF version (1.1, 1.2), we need the implementation version (myfaces 1.1, 1.3...). I was thinking about trying to read the manifest but haven't figured out a good method. This seems like it should be part of the JSF API? Any ideas? Gary [1] https://issues.apache.org/struts/browse/SHALE-418 [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java /org/apache/shale/clay/utils/JSFRuntimeTracker.java?view=markup
SV: Determining the flavor of the JSF runtime
Hi This is exactly what I was talking about. Finding something in the code that distinguishes the versions. However this is only step one. Next is to figure out which implementation (MyFaces, RI). Here one only needs to try an do a class.forName on a class in each and check for exceptions. Hermod -Opprinnelig melding- Fra: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sendt: 6. mars 2007 21:58 Til: dev@shale.apache.org Emne: Re: Determining the flavor of the JSF runtime Facelets has code to distinguish between JSF 1.1 and JSF 1.2. com.sun.facelets.util.FacesAPI. https://facelets.dev.java.net/source/browse/facelets/src/java/com/sun/facele ts/util/FacesAPI.java As Kito mentioned, it also came up at one point that this should be part of the JSF API. -- Forwarded message -- From: Jesse Alexander (KBSA 21) [EMAIL PROTECTED] Date: Oct 28, 2005 9:15 AM Subject: RE: How to find out which implementation is running To: MyFaces Discussion users@myfaces.apache.org, [EMAIL PROTECTED] Well... I see two alternatives: 1) We add one/two method to javax.faces.application.Application eg. getImplName() and getSpecVersion() But that would require a spec change... 2) We ask that at startup one of the implementation classes adds the information as a managedBean or a external-context variable This could be added also without a spec change, just need to agree with the RI-people on an identifier to use... regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Friday, October 28, 2005 4:07 PM To: MyFaces Discussion Subject: Re: How to find out which implementation is running Good question. If you devise something like this, there should also be a way to check for the spec version of the jsf implementation running. regards, Martin On 10/28/05, Jesse Alexander (KBSA 21) [EMAIL PROTECTED] wrote: Hi When I want to write a component that must run under more than JSF-implementation, I often should know (runtime not development time) which implementation is running, in order to use the correct base-classes. Has somebody devised a clever method to find out which JSF-runtime is active? Or should we add something to enable this? regards Alexander On 3/6/07, Gary VanMatre [EMAIL PROTECTED] wrote: I've been trying to determine a better strategy for detecting the supplier and version of the JSF runtime. This has to do with a open JIRA ticket [1]. I attempted to create a utility class to determine the implementor of the runtime and the JSF spec version [2]. This was a real hack but I didn't see a better way and I'm still not sure the best way to dynamically extract this version information. Besides knowing the JSF version (1.1, 1.2), we need the implementation version (myfaces 1.1, 1.3...). I was thinking about trying to read the manifest but haven't figured out a good method. This seems like it should be part of the JSF API? Any ideas? Gary [1] https://issues.apache.org/struts/browse/SHALE-418 [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java /org/apache/shale/clay/utils/JSFRuntimeTracker.java?view=markup
Promote the ShaleClayStarter archetype
Hi Now that there are a couple of tutorials on the Wiki (and more to come) covering Shale and Clay and that is sparked off by the Maven Shale/Clay starter archetype, I'd like to call for a vote to promote it so that it gets into the distro. [X] +1 Yes (non-binding) [ ] 0 Don't care [ ] -1 No way Hermod
Showing images in the Wiki
Hi I am having trouble with images not showing. According to the MoinMoin Wiki help it is supposed to be Attachment:attachmentname However they do not appear - Only the text shows. Hermod
Clay starter archetype
Hi Since the first tutorial is now on the Wiki and it is based on the archetype, could someone please apply the patches and maybe also promote it from the sandbox? http://issues.apache.org/struts/browse/SHALE-391 Hermod
SV: Clay tutorial
Hi Sorry, it's on a company internal Wiki. You are going to have to wait for the English version on the Shale Wiki. I might create a .pdf version of it after that and a Norwegian version would absolutely be an option. Hermod -Opprinnelig melding- Fra: TrippleT [mailto:[EMAIL PROTECTED] Sendt: 16. februar 2007 23:03 Til: dev@shale.apache.org Emne: Re: Clay tutorial I love to read this tutorial in norweigan language. Do you got an url to that? Thanks, Thomas (sv_SE) ;) Hermod Opstvedt wrote: Hi Recently I've been writing a rather detailed tutorial on using Clay on our company's Wiki. It's currently in Norwegian, but if there is an interest in it I would be willing to translate it to English and we could either add it to the Shake Wiki or I could submit it as a .pdf document. Would anyone of you be willing to read through it, if so? Hermod -- View this message in context: http://www.nabble.com/Clay-tutorial-tf3228604.html#a9013479 Sent from the Shale - Dev mailing list archive at Nabble.com.
SV: SV: Clay tutorial
Hi Ok. I've started translating it and need to read up on some MoinMoin stuff before I add it to the Wiki. Hermod -Opprinnelig melding- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Matthias Wessendorf Sendt: 15. februar 2007 12:10 Til: dev@shale.apache.org Emne: Re: SV: Clay tutorial a clay tut. sounds cool .-M On 2/14/07, Ole Ersoy [EMAIL PROTECTED] wrote: I'll be glad to review that as well - either in English or Norwegian :-) --- Hermod Opstvedt [EMAIL PROTECTED] wrote: Hi OK, It contains quite a bit of images and I don't know how the Shale Wiki handles these. The Wiki we are using is a TWiki wiki. Hermod -Opprinnelig melding- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Craig McClanahan Sendt: 14. februar 2007 20:29 Til: dev@shale.apache.org; [EMAIL PROTECTED] Emne: Re: Clay tutorial On 2/14/07, Hermod Opstvedt [EMAIL PROTECTED] wrote: Hi Recently I've been writing a rather detailed tutorial on using Clay on our company's Wiki. It's currently in Norwegian, but if there is an interest in it I would be willing to translate it to English and we could either add it to the Shake Wiki or I could submit it as a .pdf document. Would anyone of you be willing to read through it, if so? I sure would! There's some magic inside Clay that I certainly don't understand very well yet, and I'll bet there are lots of other folks in the same boat. Regarding format, I'd suggest the Shale Wiki so that it can be easily kept up to date as Clay evolves. Hermod Craig Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
SV: SV: Clay tutorial
Hi There a snag here - I'm not allowed to edit the page (http://wiki.apache.org/shale/ShaleAndClayTutorial?action=edit) Hermod -Opprinnelig melding- Fra: Hermod Opstvedt [mailto:[EMAIL PROTECTED] Sendt: 15. februar 2007 19:40 Til: dev@shale.apache.org Emne: SV: SV: Clay tutorial Hi Ok. I've started translating it and need to read up on some MoinMoin stuff before I add it to the Wiki. Hermod -Opprinnelig melding- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Matthias Wessendorf Sendt: 15. februar 2007 12:10 Til: dev@shale.apache.org Emne: Re: SV: Clay tutorial a clay tut. sounds cool .-M On 2/14/07, Ole Ersoy [EMAIL PROTECTED] wrote: I'll be glad to review that as well - either in English or Norwegian :-) --- Hermod Opstvedt [EMAIL PROTECTED] wrote: Hi OK, It contains quite a bit of images and I don't know how the Shale Wiki handles these. The Wiki we are using is a TWiki wiki. Hermod -Opprinnelig melding- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Craig McClanahan Sendt: 14. februar 2007 20:29 Til: dev@shale.apache.org; [EMAIL PROTECTED] Emne: Re: Clay tutorial On 2/14/07, Hermod Opstvedt [EMAIL PROTECTED] wrote: Hi Recently I've been writing a rather detailed tutorial on using Clay on our company's Wiki. It's currently in Norwegian, but if there is an interest in it I would be willing to translate it to English and we could either add it to the Shake Wiki or I could submit it as a .pdf document. Would anyone of you be willing to read through it, if so? I sure would! There's some magic inside Clay that I certainly don't understand very well yet, and I'll bet there are lots of other folks in the same boat. Regarding format, I'd suggest the Shale Wiki so that it can be easily kept up to date as Clay evolves. Hermod Craig Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Clay tutorial
Hi Recently I've been writing a rather detailed tutorial on using Clay on our company's Wiki. It's currently in Norwegian, but if there is an interest in it I would be willing to translate it to English and we could either add it to the Shake Wiki or I could submit it as a .pdf document. Would anyone of you be willing to read through it, if so? Hermod
SV: Update to Tld2ClayCfg
Hi My suggestion for the added mapping goes for the Maven build. This means that when you build Clay, the correct configuration file information is build and you don't have to handtweak it afterwards. There would be some minimal maintenance of that list when something new is added though. Hermod -Opprinnelig melding- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 14. februar 2007 17:52 Til: dev@shale.apache.org Emne: RE: Update to Tld2ClayCfg From: [EMAIL PROTECTED] Hi So should we leave the Tld2ClayCfg as it is now (with the latest patch) ? It outputs al the required components, but lacks the information that we can't get from the ld or by introspecting the tags. I think we should stick with components. There is only so much we can squeeze out of a TLD. For this reason, I think it is a good argument to setup archetypes for each component library. We will need to customize Clay for the special method bindings that various component libraries offer anyway. Another possible solution that I have is to add another section to the plugin where one could link special things like these with the componentType. This way the tool would build a complete definition file that would need no further manual tweaking. SInce these definitions only are related to a few tld's and there or not that many of them I think that this is a viable solution. That's not a bad idea but we could just as easily list multiple config files in the web.xml versus an XML document include. Hermod Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 11:38 PM To: dev@shale.apache.org Subject: Re: Update to Tld2ClayCfg From: Craig McClanahan On 2/12/07, Hermod Opstvedt wrote: Hi I updated the Tld2ClayCfg tool in order to support Validators, Converters and rendererType. As I mentioned in the issue, there is a problem with getting hold of the componentType for these. There is the possibility of assuming that the componentType is the same as the tag-class minus the Tag ending, but I don't think that will stick. So if anyone has a bright idea, please shout out. Could someone also commit the patches to the Clay starter archetype. There are som bugfixes in there. I haven't followed all the details of this, but does Clay require some association between particular converter/validator classes and part icular component classes? If it does, that doesn't really make sense to me. When you add a validator, converter or listener to a component, it requires using a nested element under the component top-level element. These nested elements, point to a top-level component definition. The Clay XML configs define component, converters, validators and listeners as top-level components. This is similar to defining a tag definition in the TLD for each associated components, validators, converters and listeners. For a top-level component definition (components, converters, validators and listeners), the componentType attribute is the JSF componentType, converterId, validatorId or the fully qualified class path to the listener. Historically, the clay config used a neutral mnemonic displayElement. A displayElement captured generic metadata about these JSF elements. We changed to component, while it was still in a bugzilla ticket, to make it more familiar with the Tapestry terminology. In hindsight, displayElement might have been a better name. For example, a custom converter with a property: Given a specific use within the application: For validators, there isn't really any formal linkage between validator classes and component classes at the JSF level. It seems to me that we should not try to enforce such a distinction in Clay either. Yeah, I think the best we can do is load the tag and determine that it extends ValidatorTag or ConverterTag and then just dump the attributes and fill the componentType with a dummy value that has to be manually addressed. That's what I did with the Trinidad library but I don't see a way to even attempt to handle action and value change listners. For example: For converters, JSF has the concept of converter-for-class ... but it is visible only in faces-config.xml not in a TLD. That is because the correct converter is selected automatically if you have a value binding on the value property, and the JSF runtime can determine the destination type. This works no matter what view handler is used, so you should be getting it for free with Clay. Using the converter value binding attribtue of the component doesn't require a Clay component defintion for the converter. It is only needed if you need to pass properties to the converter which would be handled in JSP with a custom tag. Clay
Update to Tld2ClayCfg
Hi I updated the Tld2ClayCfg tool in order to support Validators, Converters and rendererType. As I mentioned in the issue, there is a problem with getting hold of the componentType for these. There is the possibility of assuming that the componentType is the same as the tag-class minus the Tag ending, but I don't think that will stick. So if anyone has a bright idea, please shout out. Could someone also commit the patches to the Clay starter archetype. There are som bugfixes in there. Hermod
SV: svn commit: r500112 -/shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/validator-rules.xml
Se inn inline comments
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 31. januar 2007 17:27
Til: dev@shale.apache.org
Emne: RE: svn commit: r500112
-/shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/resou
rces/archetype-resources/src/main/webapp/WEB-INF/validator-rules.xml
Hi
Ok, I am ready to submit the patch for this. However there are som issues
that
need to be dealt with before I submit.
1. The tool now adds a validator attribute to each component if one is
defined
for the tld it self (It is a separate entry in the tld apart from the tags
them
self)
component jsfid=hx:commandExButton
componentType=com.ibm.faces.HtmlCommandExButton
validator=com.ibm.faces.taglib.JWLTagLibraryValidator
extends=baseComponent
There is a problem with the dtd for the Clay components here:
!ELEMENT component (description*, attributes?, symbols?, converter?, ,*,
actionListener*, valueChangeListener*, element*)
!ATTLIST component jsfid CDATA #REQUIRED
extends CDATA #IMPLIED
componentType CDATA #IMPLIED
id CDATA #IMPLIED
allowBody %Boolean; #IMPLIED
facetName CDATA #IMPLIED
Even though it is stated in the comment above the declaration :
...
validator - A component can have zero or many associated validators.
Only
components that
implement the EditableValueHolder interfaces can be assigned
validators. This
rule
is enforced at runtime and not through this document type definition.
..
It is not defined in the component it self. Also since the jsf dtd only
specifies a single validator declaration, there is no way that the Clay
compenent definition that maps jsf component libraries can have more than
one
validator assigned.
That's not exactly correct. A componnet can contain any number of
validators but
the jsfid has to be unique. This has more to do with how inheritance is
resolved.
One component definition can extend another inheriting validators. You can
add or
override validators in the sub component definition by jsfid.
However, are you saying that validator*, will not support multiple
validators?
---
No, I am considering the case where we generate this off a jsf dtd. There
can only be one Validator defined in it.
As mentioned in https://issues.apache.org/struts/browse/SHALE-402 I have
generated a clay-config file for the IBM JSF components in WAS 6.1.
There the Validator is defined as:
validator
validator-class
com.ibm.faces.taglib.JWLTagLibraryValidator
/validator-class
/validator
So back to my original question regarding the dtd and the Validator
definition - Do we both alter the dtd to support this case where we add the
validator as an attribute to the component definition:
component jsfid=hx:commandExButton
componentType=com.ibm.faces.HtmlCommandExButton
validator=com.ibm.faces.taglib.JWLTagLibraryValidator
extends=baseComponent
And also support validator as an attribute (Set) ?
---
Consider:
component jsfid=email extends=inputText id=email
attributes
set name=value value=[EMAIL PROTECTED] /
set name=size value=30 /
set name=maxlength value=50 /
set name=required value=false /
/attributes
validator jsfid=val:commonsValidatorRequired
attributes
set name=client value=true /
set name=server value=true /
set name=arg value=#{messages['rolodex.email']} /
/attributes
/validator
validator jsfid=val:commonsValidatorEmail
attributes
set name=client value=true /
set name=server value=true /
set name=arg value=#{messages['rolodex.email']} /
/attributes
/validator
/component
2. Regarding converters, I have skimmed through the trinidad stuff and the
only
reference to converters are as attributes to the tags:
attribute
nameconverter/name
rtexprvaluefalse/rtexprvalue
descriptiona converter object/description
/attribute
The converters are now mapped as attributes to the Clay components:
set name=converter bindingType=MB/set
Trinidad has a few custom converters. I think I have them all covered in
the
shale-clay-trinidad project in the sandbox.
Search for tr:convertColor in the clay config [1].
[1]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/reso
urces/META-INF/tr-incubator-m1-SNAPSHOT-config.xml?view=markup
I'll look at the dtd and you clay-config file and add support in the
generator.
---
3. The rendererType is also mapped as an attribute:
set name=rendererType value=com.ibm.faces.Button/set
Sound perfect.
Hermod
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, January 29, 2007 9:12 AM
To: dev@shale.apache.org
Subject: RE: svn commit: r500112
-/shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/r
esources/archetype-resources/src/main/webapp/WEB-INF/validator-rules.xml
Hi
I had already done the rendererType, but was waiting to file a Jira on it
until
I had added the converters and
SV: Clay, Tomahawk and jscookmenu
Hi
Ok, I'm finally having some spare time to look into this. It's no problem
getting the rendererType from components that extend UIComponentTag. Now
where do we want to put it in the clay-config?
1.
component jsfid=view componentType=javax.faces.ViewRoot
rendererType=
2.
component jsfid=view componentType=javax.faces.ViewRoot
attributes
...
set name= rendererType value=... /
...
/component
I would guess that 1 is the preferred choice, although that will mean that
we need to change the dtd.
Hermod
-Opprinnelig melding-
Fra: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Sendt: 18. desember 2006 17:43
Til: user@shale.apache.org
Emne: SV: Clay, Tomahawk and jscookmenu
Hi
I'll take a look at it.
Hermod
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 18. desember 2006 17:03
Til: user@shale.apache.org
Emne: RE: Clay, Tomahawk and jscookmenu
From: [EMAIL PROTECTED]
Hi
Gary, is this something that we need to adress in the Tld2Clayconfig tool
(rendertype) ?
That's not a bad idea. If we pulled the rendererType from the Tag, it
should
fix these components that are loose (with the rendererType).
Hermod
Gary
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 17, 2006 11:59 PM
To: user@shale.apache.org
Subject: Re: Clay, Tomahawk and jscookmenu
From: Steve Olson
Thanks for the info. I looked at both the code below and your site, and
have
a couple questions. It looks like you had to essentially render your
own menu, as if the jscookmenu renderer wasn't used. Also the call to
cmDrawFromText - the jscookmenu.js that comes with the tomahawk 1.1.3
jar
doesn't seem to define cmDrawFromText. I can see on the jscook site that
this
is a valid function so are you using a newer jscook version than the
tomhawk jar does, or am I just missing something?
Also, it looked like you had to extract the resources (.js, .gif, etc)
for
jscookmenu from the tomahawk jar into your own directories and
explicitly
include them, as if org.apache.myfaces.webapp.filter.ExtensionsFilter also
wasn't working. Is that what you had to do? Am I understanding things
correctly here?
I was hoping to get html something like this working, but this just
renders
a default submit Query button as an input control (!?):
theme=ThemeOffice
itemValue=#{messages['menu1']} action=#{homePage.menu1}/
itemValue=#{messages['menu2']} action=#{homePage.menu2}/
It'd be nice if this would rely on the tomahawk infastructure to provide
the
same rendering it does without using Clay. Is there a conflict/bug here
between Clay and tomahawk with how it renders jscookmenu controls?
If this is a bug or an RFE, I don't see anything listed in the Shale
Jira.
I'm also assuming this is a Clay issue, since it works in JSP, but maybe
that's a bad assumption :-). Anyway, I have some time available and would
be interested in contributing a patch (assuming I can figure one out :-)
if
that would be useful.
Do you agree that this is a Clay bug? Do you know of anyone else already
looking into this? Should this be a new clay Jira issue?
It looks like there are a couple issue here. The first is that the
renderType
of the jscookMenu is lost. Some of the myfaces tomahawk components
don't return / override the renderType. In this case it's picking up a
default
button renderType.
This can be easily fixed by overriding it in the Clay conifg. We will need
to
change this in the base tomahawk 1.3 config but consider the following
example:
The next problem is that the javascript is not being added. I tracked this
down
to the myfaces ExtensionsFilter. The filter injects javascript into the
response but it's insistent that the response's contentType is set so it
can
determine if it should process the resource for insertion. The
ClayViewHander is not explicitly setting the response's content type.
You have uncovered a couple bugs here. Please create a JIRA ticket
on this one (http://shale.apache.org/issue-tracking.html). I'd like to get
a
fix in before the next shale release.
Gary
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email.
This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
SV: ViewController question
Hi This was changed in 1.0.4 tree - Only request scoped beans are supported (with respect to calbacks). The docs have just not been updated. Hermod -Opprinnelig melding- Fra: Enrique Medina Montenegro [mailto:[EMAIL PROTECTED] Sendt: 9. desember 2006 10:21 Til: dev@shale.apache.org Emne: Re: ViewController question Matthias, I can confirm that session and application scoped beans do not get these *extra* services :-( Regards, Enrique Medina. On 12/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Craig, I today played around a ViewController in session scope I figured out the *extra* services aren't called. The docu says snip Declare your backing bean as a managed-bean, using a managed-bean-name value that can be mapped from the view identifier. (See DefaultViewControllerMapper for the details of the default mapping.) In nearly all circumstances, you will want the bean to be placed in request scope. /snip is it a bug, that only request scoped beans are working? I mean sometimes it is very handy to have session/application based beans Thanks! Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
SV: Security in Remoting: ClassResourceProcessor
Hi Nothing stops you from creating your own if its is disabled - A scenario like yours is by any means unsecure. Hermod -Opprinnelig melding- Fra: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sendt: 29. november 2006 14:41 Til: dev@shale.apache.org Emne: Security in Remoting: ClassResourceProcessor Hi, I think the current implementation of the ClassResourceProcessor is a security issue. The ClassResourceProcessor exposes all files in the classpath and it's enable by default. If you have e.g. your database passwords in properties files you just have to know the name and path to the file and you can read the content of the file. So I think it should at least be disabled by default. Bernhard
