Re: Shale test status
-- Original message -- From: Matthias Wessendorf [EMAIL PROTECTED] On Sun, Oct 19, 2008 at 11:34 PM, Kito Mann [EMAIL PROTECTED] wrote: Hey Simon, I don't think this has been officially decided. Check out the recent thread on this topic. However, if you're going to be making changes for JSF 2, this might be a good time to move it over to MyFaces. I don't think Gary agrees, though :-). I am also +1 on the move ;-) Humm, well, I don't understand why shale test is excluded from the normal community protocol. For goodness sakes, what if every project felt it necessary to pull commons digester into their own just because they use it. I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi, I'm working on implementing JSF 2.0 for MyFaces and as you may know, MyFaces uses Shale test for its unit testing. However, the new API and contracts involved in JSF 2.0 make it so that current test fails with an UnsupportedOperationException since some test implementations don't override the new method that weren't marked abstract for binary code compatibility. Anyway, my point is, what is the current status and roadmap for shale-test framework? Should JSF 2.0 changes be applied to it or will it be integrated in in part or completely in MyFaces with time? Thanks, ~ Simon -- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[ANNOUNCEMENT] New Shale Committer: Paul Spencer
Please join me in welcoming Paul Spencer as the newest Shale committer. Paul has been very supportive of the Shale community over the past year. Paul is also a member of the MyFaces project. Welcome, Paul!
Re: Shale Test
-- Original message -- From: Bernd Bohmann [EMAIL PROTECTED] Hello, Matthias Wessendorf schrieb: I personally only have interest in test, that's what I use on my projects. But if don't care about the rest. So, could an only 1.1 release of test work ? +1 I think we would need to vote on releasing just a 1.1 shale test library but I don't see any major issue there given the big fuss. Matthias, are you volunteering? https://issues.apache.org/struts/browse/SHALE-465 https://issues.apache.org/struts/browse/SHALE-466 https://issues.apache.org/struts/browse/SHALE-467 https://issues.apache.org/struts/browse/SHALE-468 I would like to use Shale Test for MyFaces Tobago, but all patches have only been applied to trunk. Should I resend the patches for the 1.0 branch? That's odd. Maybe Matthias had some reason for only applying these to the snapshot branch. Regards Bernd Gary
Re: Shale Test
-- Original message -- From: Kito Mann [EMAIL PROTECTED] On Tue, Sep 30, 2008 at 11:23 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 6:22 PM, Kito Mann [EMAIL PROTECTED] wrote: That's fine, but I don't really see _anyone_ driving releases :-). What's the problem with letting Shale Test move somewhere else? The problem, though, is that Shale Test is part of a project that has stagnated. So, even if Shale Test moves forward, it's difficult to get traction if the whole project is perceived as stale. Do you see what I'm saying? If there are so many people out there who want to help move Shale Test forward, then we would love for them to step up and start contributing. Look at it this way: I use Shale in at least one project at work, so I have a vested interest in it continuing to work. Now a whole bunch of people from Project Foo think Shale needs to move forward and that it can move forward better over at Project Foo. But I've never seen code from the folks at Project Foo. I don't know their attitudes or development styles. I don't know how they work with others. I don't know if they will release it under a license I am comfortable with. How can I agree in good faith to just hand over the management of Shale to Project Foo when I don't know these things? We are commissioned by the ASF to manage the Shale project. You could make a decent argument that we have not done a very good job of managing the project. But we cannot recommend to the ASF in good faith that the best direction for the project is to send it to somebody else who we don't know. So that brings us back to this: If people think Shale Test needs to move forward then I would cordially and sincerely invite them to come join the dev list and start submitting patches. Point me to the patches that have not been responded to. Point me to the questions and requests that are not being answered. When I see that I can begin to give credibility to your argument that Shale would be better managed elsewhere. Just so I am clear: the motive of this post is not to be dramatic or troll or anything like that. I want to see Shale move forward too. If the best thing is for it to move elsewhere, then I will be the first to vote for that. But I can't trust who I don't know. Send those folks over here and let's engage in some discussion and get some stuff done. Ok. I'll certainly ping Stan and company. But I think my sentiment is valid even if we just move it to MyFaces. That, to me, would make plenty of sense because plenty of the MyFaces projects use it. Well, we have several myfaces committers on the shale project. I'm not convinced that moving the code there under different package names would make the bits work better. -- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: Shale Test
-- Original message -- From: Kito Mann [EMAIL PROTECTED] On Thu, Sep 25, 2008 at 5:11 PM, Gary VanMatre [EMAIL PROTECTED]wrote: -- Original message -- From: Kito Mann [EMAIL PROTECTED] Hello everyone, At JSFOne we were discussing Shale Test, and again the idea of moving it out of Shale popped up. With so little activity in the Shale project, I'd like to bring up the issue of migrating it to MyFaces proper, or out of MyFaces all-together. Thoughts? Any contributions to the shale project are much appreciated. What do you mean by out of MyFaces all-together? Kito, do you have interest in supporting this library under the shale community? Well, there has been interest in supporting Shale Test inside of JSFUnit -- that's what I meant by out of MyFaces all-together. Basically, I think the community could use and updated and and active version of Shale Test, and the Shale community doesn't seem to have the bandwidth (or interest) in making that happen. Given the fact that a lot of MyFaces projects use it, I could see how MyFaces may be a better place for it, *if* people in that community have cycles for it. Otherwise, it may fare better somewhere else. I certainly have interest in working on Shale Test regardless of where it is (I have a nice little Spring integration class, for instance), but I don't have the bandwidth to personally push the project forward. I see. Thanks for taking the time to explain. Shale welcomes anyone that is willing to contribute to the project in the way of documentation or code contributions. Since the Shale project is not indirectly sponsored by a commercial entity, we dont necessary have another product driving the release. Im certain that Shale would be more than willing to work with the Jboss group within the shale community. Gary ~~~ Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -- ~~~ Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: Shale Test
-- Original message -- From: Kito Mann [EMAIL PROTECTED] Hello everyone, At JSFOne we were discussing Shale Test, and again the idea of moving it out of Shale popped up. With so little activity in the Shale project, I'd like to bring up the issue of migrating it to MyFaces proper, or out of MyFaces all-together. Thoughts? Any contributions to the shale project are much appreciated. What do you mean by out of MyFaces all-together? Kito, do you have interest in supporting this library under the shale community? Gary ~~~ Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
Re: [VOTE] [Modified] Release Shale 1.0.5
I reviewed the bits using WebLogic 10.3 server. The only issue I had as with the shale-mailreader-jpa project. The shale-core still has a reference to the commons validator tag in the TLD. WLS goes out of its way to validate the faces configs and tld's. Since the commons-validator jar was not included, the project was not able to load. We should clean up the core TLD in our trunk before a 1.1 release but most app servers are more forgiving of this sorta thing. The only other issue that always trips me up is the shale remoting tests. If you invoke the ajax test before the remoting test and use the navigation back to the primary window (forward), it screws up the next tests that are invoked using outputLinks by prepending /ajax to the url. +1 Release these artifacts as Shale 1.0.5 Gary -- Original message -- From: Greg Reddin [EMAIL PROTECTED] This is a resubmit of the Shale 1.0.5 release vote. (Sorry for the delayed posting). I've modified the set of artifacts to the list below. (1) The repository has been tagged here (I did not modify the tag): http://svn.apache.org/repos/asf/shale/framework/tags/SHALE_1_0_5/ (2) The Maven artifacts are staged here: http://people.apache.org/builds/shale/shale-1.0.5/m2-staging-repository/ org.apache.shale.extras:mailreader-jpa:1.0.5 org.apache.shale:shale-application:1.0.5 org.apache.shale:shale-apps-parent:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-clay-usecases:1.0.5 org.apache.shale:shale-clay:1.0.5 org.apache.shale:shale-core:1.0.5 org.apache.shale:shale-dialog-basic:1.0.5 org.apache.shale:shale-dialog-scxml:1.0.5 org.apache.shale:shale-dialog:1.0.5 org.apache.shale:shale-mailreader-jpa:1.0.5 org.apache.shale:shale-mailreader:1.0.5 org.apache.shale:shale-parent:1.0.5 org.apache.shale:shale-remoting:1.0.5 org.apache.shale:shale-spring:1.0.5 org.apache.shale:shale-sql-browser:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-tiger:1.0.5 org.apache.shale:shale-usecases:1.0.5 org.apache.shale:shale-validator:1.0.5 org.apache.shale:shale-view:1.0.5 (3) The release artifacts are available here: http://people.apache.org/builds/shale/shale-1.0.5/dist/ mailreader-jpa-1.0.5.zip shale-blank-1.0.5.zip shale-clay-usecases-1.0.5.zip shale-framework-1.0.5.zip shale-mailreader-1.0.5.zip shale-mailreader-jpa-1.0.5.zip shale-sql-browser-1.0.5.zip shale-usecases-1.0.5.zip (4) The release notes are here, for ready reference: http://people.apache.org/~greddin/release-notes-1.0.5.html (5) Vote Please review these artifacts, signatures and checksums, and vote whether we should release them as Apache Shale version 1.0.5. --8 [ ] +1 Release these artifacts as Shale 1.0.5 [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released A quality vote (per module, where necessary) will be held later on if this passes. Thank you!! Greg
Re: [VOTE] Release Shale Master POM Version 3
+1 Gary -- Original message -- From: Greg Reddin [EMAIL PROTECTED] This is the formal vote for the new Shale master POM version 3. The former vote for the same version was cancelled due to problems in the POM. The POM was corrected and the release process was re-executed since the previous release had not been copied to the main repository. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/sha le-master/3/
Re: Shale validator wish list
From: Rahul Akolkar [EMAIL PROTECTED] Could you please open separate tickets for each item, along with any patches you'd like to propose, in the Shale JIRA [1] (Validator component) ? Unless someone looks at this immediately, that will better ensure that these stay on some roadmap. I agree. These are good ideas and should be considered for a 1.1.x release. -Rahul Gary [1] https://issues.apache.org/struts/browse/SHALE On 4/16/08, Jeff Tsay wrote: Hi, I've been trying to integrate the Shale validator stuff with xulfaces. I've come across the following problems, some of which I have fixes for. Your input would be appreciated, hope I can check some of the stuff in. 1) As I mentioned in the shale user mailing list, when the validator script gets rendered, it outputs raw Javascript inside the
Re: [VOTE] Release Shale Master POM Version 3
+1 Gary -- Original message -- From: Rahul Akolkar [EMAIL PROTECTED] On Wed, Apr 9, 2008 at 11:59 AM, Greg Reddin [EMAIL PROTECTED] wrote: This is the formal vote for the new Shale master POM version 3. I would appreciate a thorough review of these artifacts since I am a release manager newbie :-) You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom snip/ +1 -Rahul Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/sha le-master/3/
Re: @SHALE-442
Hi. I want to fix this bug 442 and want to ask some question here about doing that, if thats ok, i'll hope so. I'll fixed the decorator not to apply shales validator renderer if the renderer family matches the ajax stuff, which let them work again. However this seams not the ultimate approach to me because there are so many different familys and renderers which should not be decorated, that i'll have to code everytime they change. Are there any suggestions or ideas (already) how this should be done the right way? I have struggled with this issue and do not see a clean/easy fix. Most rich validators are bundled with component libraries that have a unique rendering strategy for script. In the case of shale's common validator, the script needs to be built in the context of rendering. This is important for children of the UIData component family. Unfortunately, there is not yet a generic way to extend a renderer without knowledge of the component library. This issue surfaces with Tomahawks Ajax renderer interface contract. However, I believe that JSF 2.0 will provide listeners that can be attached to components and fired at render time but we'll have to wait and see if that can be used to build rich validators that are not coupled to a single component library. Or, maybe bytecode injection would be the ticket? I guess we could take some studies of tapestry 5? Maybe inject our own listeners :-) Torsten Gary---BeginMessage--- Hi. I want to fix this bug 442 and want to ask some question here about doing that, if thats ok, i'll hope so. I'll fixed the decorator not to apply shales validator renderer if the renderer family matches the ajax stuff, which let them work again. However this seams not the ultimate approach to me because there are so many different familys and renderers which should not be decorated, that i'll have to code everytime they change. Are there any suggestions or ideas (already) how this should be done the right way? Torsten smime.p7s Description: S/MIME cryptographic signature ---End Message---
Re: 1.0.5 Release
From: Greg Reddin [EMAIL PROTECTED] I've fixed the build problems in the 1_0_X branch and completed the extraction of the Tiles integration component. There are two Clay-related tickets still posted to 1.0.5 [1] that don't seem critical to me. It's been some time since I've looked at this one but I think it was fixed and this bug is a duplicate [1]. [1] https://issues.apache.org/struts/browse/SHALE-390 I'd like to volunteer to be the RM for a 1.0.5 release if everybody else is on board. I'm not a fast-mover and I'm not sure what my schedule will be but I would like to do it so I can understand the process. I'll start by reading up on the release process on the wiki and we can take it from there. Let me know if you have any objections to this direction. +1 I'll help out also. Thanks, Greg Gary [1] https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hide sorter/order=DESCsorter/field=priorityresolution=-1pid=10130fixfor=21751
Re: [jira] Commented: (SHALE-475) Setup managed bean in JSF 1.2
From: Shankar (JIRA) [EMAIL PROTECTED]
[
https://issues.apache.org/struts/browse/SHALE-475?page=com.atlassian.jira.plugin
.system.issuetabpanels:comment-tabpanelfocusedCommentId=43512#action_43512 ]
Shankar commented on SHALE-475:
---
Is there any workaround for this issue??
Try explicitly adding LeftNav to a scope. The mock EL has no knowledge of
#{leftNav}. Or,
try #{sessionScope.leftNav}.
Gary
Setup managed bean in JSF 1.2
-
Key: SHALE-475
URL: https://issues.apache.org/struts/browse/SHALE-475
Project: Shale
Issue Type: Bug
Components: Test
Affects Versions: 1.0.4
Environment: Java 5, OS X 10.4.10, JSF 1.2
Reporter: Chris Keefer
When trying to add a managed bean to the Mock Faces Context a Missing
Resource
Exception is thrown. The test class extends AbstractJsfTestCase. The setUp
method is the following:
public void setUp() throws Exception {
super.setUp();
// add managed bean
_factory = application.getExpressionFactory();
_elContext = MockFacesContext.getCurrentInstance().getELContext();
ValueExpression expression =
_factory.createValueExpression(_elContext, #{leftNav},
LeftNav.class);
MockServletContext context =
(MockServletContext)session.getServletContext();
context.setDocumentRoot(new File(DOC_ROOT));
expression.setValue(_elContext, new LeftNav());
}
The last line throws the MissingResourceException.
java.util.MissingResourceException: Can't find bundle for base name
leftNav,
locale en_US
at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:836)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:805)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:576)
at
org.apache.shale.test.mock.MockApplication12.getResourceBundle(MockApplication12
.java:261)
at
org.apache.shale.test.el.FacesResourceBundleELResolver.setValue(FacesResourceBun
dleELResolver.java:202)
at javax.el.CompositeELResolver.setValue(CompositeELResolver.java:283)
at
org.apache.shale.test.el.MockValueExpression.setValue(MockValueExpression.java:2
48)
--Chris
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: Merging Shale into MyFaces
From: Pavel Savara [EMAIL PROTECTED] but I'm having a hard time seeing benefits over Facelets and Clay. What I see as benefit for tiles is possibility to define another tiles.xml config which specify what page should be displayed for different locale. So you don't have only localized messages and text but complete web page layout event you can serve completely different web page under the same url for different locale. Not sure it this is possible in clay or facelets. FWIW, this is definitly possible in clay. Pavel Gary -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:47 PM To: dev@shale.apache.org Subject: Re: Merging Shale into MyFaces On 10/22/07, Antonio Petrelli wrote: Tiles works with FreeMarker and Struts 2 too. And sincerely I think that it could be used for JSF users, if it only gets more support (don't look at me, I don't know anything about JSF :-) ). It could be used, but I'm not sure how practical it is. We've seen several users express interest, but I'm having a hard time seeing benefits over Facelets and Clay. I guess if you're employer-constrained into using JSP then Tiles might be a good option. Greg
Re: MyFaces
From: samju [EMAIL PROTECTED] So Mr. Kito, need a answer. Wich kind of things have changed? Why is it so quiet around Shale? What is the Problem with Shale? does Shale still a modern web application framework? PL please give a declaration. I see two issues here. The first is that the shale volunteers have been distracted with life events. I personally have been consumed with a new job trying to catch up on two years of product development and have not made time to participate. The second issue is that JSF is starting to mature. The third JSF specification is in the works. Some of the Shale ideas will make their way into the JSF 2 specification others could also standardize by merging two similar implementations. I would be supportive of a merger with Myfaces for these two reasons. Sam Gary kito99 wrote: So, here's a question. I know originally some people on the MyFaces team thought that Shale should be part of MyFaces. At the time, I know Craig wasn't interested. However, things have changed, and I think Shale could really benefit from the MyFaces community, especially since they are now starting to duplicate some of Shale's functionality (i.e. Orchestra's View Controller). Thoughts? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -- View this message in context: http://www.nabble.com/MyFaces-tf4643427.html#a13295601 Sent from the Shale - Dev mailing list archive at Nabble.com.
Re: svn commit: r558812 [1/4]
From: Rahul Akolkar [EMAIL PROTECTED] On 7/24/07, Gary VanMatre wrote: Thanks for talking a look Rahul. We also have an issue with the parent pom from the plugin pom. I created the folder structure base on the pde maven plugin doc. The extra plugins folder hides the parent pom. Do you know if there is a way to override the location of the parent pom? I thought that I had seen that some place. Thanks for the detailed comments Gary! Sorry, I was mostly offline for a couple of days, and I see I'm too late to be of any help here since this seems to be taken care of (BTW, I didn't know the answer, but would have looked for it for a few minutes ;-) No worries. I finally looked in the XSD :-) We will need to decide where to put this guy once it leaves the sandbox. I thought we might want to add it under tools but we would need to add a parent pom. It would be nice if we could add it to the nightly builds but I'm not sure how that would fit into continuum. The big issue is that eclipse has to be installed for the build to work. -Rahul Gary
Re: svn commit: r558812 [1/4]
From: Rahul Akolkar [EMAIL PROTECTED] On 7/23/07, [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Mon Jul 23 10:51:09 2007 New Revision: 558812 Added: shale/sandbox/shale-eclipse-plugins/ shale/sandbox/shale-eclipse-plugins/plugins/ shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/ This one is bogus: shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/.class path (with props) We need the .project and .classpath since this plugin needs eclipse to deploy the project. I don't think maven will completely generate these. shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/.proje ct (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/META-I NF/ The manifest for this plugin project contains a bunch of extra stuff. In fact, within the eclipse IDE, you can use the manifest editor to export a deployable plugin. The build.properties is linked to the manifest. shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/META-I NF/MANIFEST.MF (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/build. properties (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/icons/ Ya, that one can go - guess you know what OS I use. shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/icons/ Thumbs.db (with props) Stowaway? Thanks for talking a look Rahul. We also have an issue with the parent pom from the plugin pom. I created the folder structure base on the pde maven plugin doc. The extra plugins folder hides the parent pom. Do you know if there is a way to override the location of the parent pom? I thought that I had seen that some place. -Rahul Gary
Re: Publishing the Clay Plugin for Eclipse (WAS: Re: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution)
From: Antonio Petrelli [EMAIL PROTECTED] 2007/7/16, Gary VanMatre : From: Antonio Petrelli 2007/7/15, Gary VanMatre : I don't think we can use a standard maven setup to build the plugin project (any ideas?). At Struts the sandbox is also a Maven project (child of struts-master), and the sandboxed projects are children of project sandbox. That's a good idea and how some of our sandbox projects are organized. I was being very vague in my question. The eclipse plugin needs several dependent jar files but I don't believe there is an archetype for an eclipse plugin project. I believe that you have to use the IDE to deploy a plugin project so that it can be used. I think we could use maven to pull the dependent jars for a maven repository but I'm not sure of the best way to override the default behavior of a jar archetype. The plugin expects the dependent jars to be in a lib folder under the project folder. I'm just learning about these plugin projects so any tips on the best way to manage would be greatly. After a bit of googling I found this: http://mojo.codehaus.org/pde-maven-plugin/ It seems that it can create an Eclipse plugin update site, thought it seems to lack a bit of documentation... better than nothing :-) Ah, very good. I'll take a look. Thanks for the tip. Antonio Gary
Re: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution
From: Wendy Smoak [EMAIL PROTECTED] On 7/11/07, Wendy Smoak wrote: 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. The IP Clearance thread on the [EMAIL PROTECTED] list is here: http://www.nabble.com/-IP-CLEARANCE--Shale-Clay-Plugin-for-Eclipse-contribution- from-Ryan-Wynn-t4068969.html I won't be around much next week, so assuming this vote passes and no one votes -1 on the incubator thread, feel free to go ahead and import the code. 72 hours for the Incubator thread ends Sunday 9AM MST (GMT -7). I'll import it into a clay-plugin-for-eclipse folder in the sandbox early next week. We will need a maven build to resolve the dependencies. The eclipse project references several jar's in a lib folder. I don't think we can use a standard maven setup to build the plugin project (any ideas?). However, we can work it out in the sandbox before finding its home. Ryan, thanks for your patience while we sorted out the paperwork. I'm sorry it took so long! -- Wendy Gary
Re: Possible Contribs
From: Ian.Priest [EMAIL PROTECTED]
Hi,
I have a couple of possible contributions...
1. Clay locale-aware import: When using clay to import an html
file, will attempt to load locale specific files in the style of a
message bundle. So if the file name is basename.html will attempt to
load (in order):
baseName + _ + language + _ + country + _ + variant +
.html
baseName + _ + language + _ + country + .html
baseName + _ + language + .html
baseName.html
Done by over-riding protected ComponentBean
getRootElement() in Clay.java. Very handy for internationalisation!
2. Property expansion just like in ant property files, but in
LoadBundle. Use LoadBundle to load a property file and use properties
internally in the file like this...
property.world=World
property.helloworld=Hello ${property.world}
Done by some extra processing in the get() method of the
map. (If in the example above ${property.world} can't be found it'll
return Hello ??property.world??)
Both changes are in project-specific extended classes, so not quite
contrib-ready, but if there's enough interest in these new features
then I'll spend a couple of hours updating base classes and uploading.
It'd also be useful to know the proceedure for a contrib: raise a jira
and attach a patch file?
Those ideas are very interesting. I worked on a web application that was a
front-end for retirement services that we miss-used the variant of the locale
to represent various customers. This allowed us to easily skin the site and
since is was based in the US, we didn't have a use for the language aspect
:--).
JIRA is the best way to share source. This sounds like a useful feature.
Cheers,
Ian.
Gary
Re: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution
+1 Gary -- Original message -- From: Matthias Wessendorf [EMAIL PROTECTED] +1 On 7/12/07, Wendy Smoak wrote: On 7/11/07, Wendy Smoak wrote: 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. ... [ ] +1 - Let's accept the contribution [ ] -1 - We should not accept it because... +1 -- Wendy -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Any one plans to fix SHALE-409 bug?
From: [EMAIL PROTECTED]
I have successfully tested to comment the second loop:
// Second select all remaining instances, which will include
annotated
// managed beans if Shale Tiger is present
/*
entries = map.entrySet().iterator();
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if (!list.contains(entry.getKey())) {
list.add(entry.getKey());
}
}*/
Is there any one can try it and plans to release the fix?
The problem with commenting out this loop is that we might
break someone else's application. The second loop forces
the destroy method to be invoked for beans with the @Destroy
annotation before the response has completed and the faces
context released.
I've been looking at this one off and on. At first I thought we
could just invoke the LifecycleListener from the ViewPhaseListener
but we don't have ServletContextEvent there.
Another option might be to add a destroy method to the
ViewControllerCallbacks class. This utility bean is registered as
a managed bean. The tiger library overrides the registered bean
to look for the @Preprocess and @Prerender runtime method
annotations. The ViewControllerCallbacks2 class would inspect
for the @Destroy annotation or the other interfaces.
We could remove the second loop and modify the first to use the
ViewControllerCallbacks bean.
Consider:
// First select all the ViewController and AbstractRequestBean instances
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if
(getViewControllerCallbacks(event.getFacesContext()).hasDestroy(entry.getValue()))
{
list.add(entry.getKey());
}
}
What do you think?
Can I help you?
Thanks in advance
Mario
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any
other
use of the email by you is prohibited.
Re: Shale - Release
From: Craig McClanahan [EMAIL PROTECTED] Sorry for the late response ... still catching up from a backlog due to being on the road for most of May. Comments below. On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? My personal preference would be for scenario A over scenario B or C, but with a twist ... target the JSF 1.2 based stuff for a 2.x release series, rather than 1.1 or 1.2. Why? Because a redesign of the existing APIs to take JSF 1.2 into account (and therefore also become dependent on Java SE 5) is very likely to require some significant changes (just as one example, much of tiger basically goes away and becomes part of the core functionality in view and other places), so upping the major version number would be more appropriate. I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? Version numbers aside, I would prefer A over B. We need to put out a new release anyway; the ease of use additions in the current trunk are modest but nice, and if we focused on just finishing 1.1 we might actually get a release out this year :-). +1 I don't like C -- we still want to have the *ability* to go back and do a 1.0.5 if some security problem or something rears its head; in the mean time, lets just get 1.1 done and out the door while we start talking about what the future might hold. And that starts from us (yes, me included :-) rolling up our sleeves and addressing the current issues in the trunk code -- and *perhaps* backporting bugfixes to the 1.0 branch, but that needn't be a priority. -Rahul Craig Gary
Re: Shale - Release
From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. Agreed. I've been meaning (for months) to update the Tiles support and haven't gotten around to it. I'll try to make that a priority. That would be good and a Tiles usecase would also be helpful. I think there is a few bug we need to fix in the view controller before the next release. Greg Gary
Re: Shale - Release
From: Rahul Akolkar [EMAIL PROTECTED] On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? I can see how A would provide a good match to JSF but the question is how many new features do we want to target at JSF 1.1 when 1.2 is the new frontier. I'd rather target the trunk at JSF 1.2/ JDK 1.5 so the trunk is always the latest. -Rahul Gary
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Yeah, that's weird. Especially if you google search Sun proprietary/confidential CDDL. Myfaces is using the same DTD here [1]? You should ask someone in licensing at apache. Maybe you can get an answer in less time [2]. [1] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/WEB-INF/examples-config.xml?view=markup [2] https://issues.apache.org/struts/browse/SHALE-444 Gary -- Original message -- From: Niall Pemberton [EMAIL PROTECTED] Forwarding to the Shale project, which has the same issue: http://tinyurl.com/28e558 Niall On 6/21/07, Craig L Russell wrote: I've been working with Sun to get the appropriate legal notices changed in the relevant files: the xsd for faces 1.2 and the dtd for faces 1.0 and 1.1. Please take a look at the newly updated files at: http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd http://java.sun.com/dtd/web-facesconfig_1_0.dtd http://java.sun.com/dtd/web-facesconfig_1_1.dtd The notices in these files should be self-explanatory. The files in the faces repository should be refreshed with the latest versions from the web. The NOTICE file in the distribution should be updated to reflect the CDDL license (we don't want the GPL license option do we). If there are other similar cases, please let me know and I'll try to get them updated as well. Regards, Craig On May 21, 2007, at 2:19 PM, Bill Stoddard wrote: Does anyone here besides me see a problem with this copyright: appearing in these two files? http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/ resources/org/apache/myfaces/resource/web-facesconfig_1_0.dtd? view=markup http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/ resources/org/apache/myfaces/resource/web-facesconfig_1_1.dtd? revision=374886view=markup These two DTDs are part of the JSR 127 spec, so they should not be Sun proprietary/confidential. Maybe the comments are proprietary/ confidential? Am I wrong for being annoyed that someone with commit privs project would check files into an ASF repo with this copyright statement, regardless of the technical justification? Bill - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: [jira] Commented: (SHALE-444) Eclipse Plugin
Thanks Henri! Gary -- Original message -- From: Henri Yandell (JIRA) [EMAIL PROTECTED] [ https://issues.apache.org/struts/browse/SHALE-444?page=com.atlassian.jira.plugin .system.issuetabpanels:comment-tabpanel#action_41117 ] Henri Yandell commented on SHALE-444: - Sadly both of you are right. The Incubator stuff currently says a grant is needed, and the way of thinking seems to be that it shouldn't. Am talking to legal about getting this sorted. Eclipse Plugin -- Key: SHALE-444 URL: https://issues.apache.org/struts/browse/SHALE-444 Project: Shale Issue Type: New Feature Components: Clay Environment: Any environment supported by Eclipse Reporter: Ryan Wynn Attachments: shale-clay-plugin-src.zip Provide a clay plugin for eclipse. Create a visual editor targeted towards creating/maintaining clay component metadata. Support autodetection of clay component definitions in the workspace. Allow component extension through drag and drop from a component palette. Provide autocompletion of managed bean names and methods. Support both visual and text modes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SHALE-409 Bug
From: Craig McClanahan [EMAIL PROTECTED] On 5/1/07, Gary VanMatre wrote: From: hughes.matt As best as I can tell there is a bug in the ViewPhaseListener in shale-view that is breaking other libraries, namely ajax4jsf by removing ALL entries from the request map. I'd gladly fix this, but I can't tell what the code should be doing. What I think is going on here is that the phase listener is collecting ViewController objects that are explicitly removed from request scope. Forcing the object to be removed will fire the destroy callback method on the shale enhanced managed beans [1]. Yes, that is definitely the intent here. I think the second loop should be looking for realization/ generalization the of the View annotation, AbstractApplication, AbstractRequestBean, AbstractSessionBean, and ViewController versus blindly treating every request value as one of those types. We're talking about the afterRenderResponse() method, right? The first loop takes care of ViewController (which therefore includes AbstractViewController) and AbstractRequestBean. There is no need to deal with AbstractSessionBean and AbstractApplicationBean, because those never get installed in request scope. The *intent* of the second loop is to pick up beans from shale-tiger that might have been annotated with @Bean or @View, but without requiring JDK 1.5. Unfortunately, it is picking up *all* remaining request scope beans. I think the right fix is to place the intended logic of the second loop in a phase listener in shale-tiger instead of in shale-view. Gosh, it would be nice if we could just lock into JDK 1.5 :-) Craig [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/ apache/shale/view/faces/LifecycleListener.java?view=markup I have detailed the bug here: https://issues.apache.org/struts/browse/SHALE-409#action_40918 https://issues.apache.org/struts/browse/SHALE-409 -- View this message in context: http://www.nabble.com/SHALE-409-Bug-tf3676627.html#a10273870 Sent from the Shale - Dev mailing list archive at Nabble.com. Gary
Re: SHALE-409 Bug
From: hughes.matt [EMAIL PROTECTED] As best as I can tell there is a bug in the ViewPhaseListener in shale-view that is breaking other libraries, namely ajax4jsf by removing ALL entries from the request map. I'd gladly fix this, but I can't tell what the code should be doing. What I think is going on here is that the phase listener is collecting ViewController objects that are explicitly removed from request scope. Forcing the object to be removed will fire the destroy callback method on the shale enhanced managed beans [1]. I think the second loop should be looking for realization/ generalization the of the View annotation, AbstractApplication, AbstractRequestBean, AbstractSessionBean, and ViewController versus blindly treating every request value as one of those types. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/LifecycleListener.java?view=markup I have detailed the bug here: https://issues.apache.org/struts/browse/SHALE-409#action_40918 https://issues.apache.org/struts/browse/SHALE-409 -- View this message in context: http://www.nabble.com/SHALE-409-Bug-tf3676627.html#a10273870 Sent from the Shale - Dev mailing list archive at Nabble.com. Gary
Re: svn commit: r518103 - /shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
From: Rahul Akolkar [EMAIL PROTECTED]
On 3/14/07, [EMAIL PROTECTED] wrote:
Author: hermod
Date: Wed Mar 14 04:43:53 2007
New Revision: 518103
URL: http://svn.apache.org/viewvc?view=revrev=518103
Log:
Added fix for SHALE-424. ComponentConfigBean now checks it the config file
is
empty before trying to create a URL from it
Modified:
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/bean
s/ComponentConfigBean.java
Modified:
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/bean
s/ComponentConfigBean.java
URL:
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/
apache/shale/clay/config/beans/ComponentConfigBean.java?view=diffrev=518103r1=
518102r2=518103
==
---
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/bean
s/ComponentConfigBean.java (original)
+++
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/bean
s/ComponentConfigBean.java Wed Mar 14 04:43:53 2007
@@ -37,6 +37,7 @@
import javax.servlet.ServletContext;
+import org.apache.commons.lang.StringUtils;
I think we should inline the StringUtils.isEmpty(String) call below.
This will avoid an explicit dependency on Commons Lang, which is
probably good unless we find ourselves inlining many bits, and over
and over.
Apparently, the only reason this builds is because Commons Lang is
pulled in transitively? (don't think we have an explicit
for it).
Yeah, I guess it must be a transitive dependency.
I agree. It is a handy method but doesn't saves much here.
This looks like another thing that C# ripped off :-)
string.Empty
-Rahul
Gary
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shale.clay.config.ClayConfigParser;
@@ -270,12 +271,15 @@
urls.add(ui.nextElement());
}
} else {
- URL url = context.getResource(configFile.toString());
- if (url == null) {
- throw new
PageNotFoundException(messages.getMessage(file.notfound,
- new Object[] {configFile.toString()}),
configFile.toString());
- }
+ if(configFile!=null
!StringUtils.isEmpty(configFile.toString()))
+ {
+ URL url =
context.getResource(configFile.toString());
+ if (url == null) {
+ throw new
PageNotFoundException(messages.getMessage(file.notfound,
+ new Object[] {configFile.toString()}),
configFile.toString());
+ }
urls.add(url);
+ }
}
} catch (IOException e) {
log.error(e);
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 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. Gary [1] http://issues.apache.org/jira/browse/MYFACES-219?page=com.atlassian.jira.plugin. 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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
[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
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
Re: Determining the flavor of the JSF runtime
From: Mike Kienenberger [EMAIL PROTECTED] 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/facelets/u til/FacesAPI.java Ah, looking at the API signatures is a good way to tell the difference between the JSF versions. In addition I need to find the version of myfaces to address the change in the view root between 1.1 and greater. Any ideas? As Kito mentioned, it also came up at one point that this should be part of the JSF API. I agree that should be part of the API. It looks like the 1.2 RI has the beginnings of this, com.sun.faces.config.JSFVersionTracker. Another thing that really bugs me is that the state marker is not standardized. Good gravy, what's up with that? com.sun.faces.saveStateFieldMaker ~com.sun.faces.saveStateFieldMarker~ !--@@JSF_FORM_STATE_MARKER@@-- I haven't looked to see what myfaces 1.2 is going to use... I'd also like to see a better strategy for allowing multiple view composition technologies to co-exist. The single suffix is to limiting. It would also be nice if there was a standard API for how JSP tags keep track of their components and parents. With this we might be able to mix types of templates. Use a rich solution for defining the layout but still be able to use jsp fragments. Gary -- Forwarded message -- From: Jesse Alexander (KBSA 21) Date: Oct 28, 2005 9:15 AM Subject: RE: How to find out which implementation is running To: MyFaces Discussion , [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) 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 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
Re: SV: Determining the flavor of the JSF runtime
From: Hermod Opstvedt [EMAIL PROTECTED] 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. Yeah, that's a real drag but I can't think of a better solution either. It will take some digging to figure out an API change or class that will distinguish a release. 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) Date: Oct 28, 2005 9:15 AM Subject: RE: How to find out which implementation is running To: MyFaces Discussion , [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) 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 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
Re: Promote the ShaleClayStarter archetype
From: Cedric Dumoulin [EMAIL PROTECTED] Hi, The tutorial and the ShaleClayStarter kit is really a nice work, but the starter kit doesn't work from scratch for me :-( I have tried to use it, and got an error about a missing file. I have corrected the error by adding chain-config.xml (copied from another example) in the sources, recompiled and try it again. Am I the only one having this problem ? Before promoting the starter kit, I suggest : * to correct the above error if it is an error. * to use more friendly name for the classes like TestVC (MyViewController ? TestViewController ? ...) Cedric, thanks for reporting this problem and for the suggestions. The author of Tiles is always welcome in Clay talk. Gary Cedric Hermod Opstvedt wrote: 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
Re: Promote the ShaleClayStarter archetype
From: Hermod Opstvedt [EMAIL PROTECTED] 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 [ ] 0 Don't care [ ] -1 No way Hermod Gary
Publishing site docs
Hey Guys, I just changed some site documentation and need to push it out to the web server. How have you infrastructure types been handling this? I'd rather generate it locally instead of setting up maven on my account @ people.apache.org. What's the best way to handle this maven mavens? Gary
Re: Publishing site docs
From: Wendy Smoak [EMAIL PROTECTED] On 2/25/07, Gary VanMatre wrote: I just changed some site documentation and need to push it out to the web server. How have you infrastructure types been handling this? I'd rather generate it locally instead of setting up maven on my account @ people.apache.org. What's the best way to handle this maven mavens? The easiest thing is to just wait and the Continuum instance on the MyFaces zone will do it daily. Here's the latest site deployment: http://myfaces.zones.apache.org:8081/continuum/buildResult.action?buildId=2971p rojectId=4 If you want to publish it before then, mvn site-deploy from the shale-parent pom should work. Nah, I'll wait :-). I didn't realize it was all automated now. Very nice.. Thanks Wendy. You don't need to set up Maven on people.a.o, but you will need ssh keys in place, or you'll get prompted for your password multiple times. -- Wendy Gary
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 will also allow you to bind converters, validators and listeners to backing beans - a JSF 1.2 feature. Outside of that, it should be technically possible to configure any converter on any component that implements ValueHolder, and to configure any validator on any component that implements EditableValueHolder. It's unfortunately we can't rip all of the clay config from the TLD's. Maybe
Re: Update to Tld2ClayCfg
From: Craig McClanahan [EMAIL PROTECTED] 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: component jsfid=myconverter componentType=myregisteredConverterId attributes set name=customProperty bindingType=Early / /attributes /component Given a specific use within the application: component jsfid=myinputwidget extends=inputText attributes/ conveter jsfid=myconverter set name=customProperty value=something / /converter /component 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: component jsfid=setActionListener componentType=FIXME.Tagclassname attributes set name=from bindingType=VB/ set name=to bindingType=VB/ /attributes /component 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 will also allow you to bind converters, validators and listeners to backing beans - a JSF 1.2 feature. Outside of that, it should be technically possible to configure any converter on any component that implements ValueHolder, and to configure any validator on any component that implements EditableValueHolder. It's unfortunately we can't rip all of the clay config from the TLD's. Maybe in the future, this metadata could be ripped from mandated annotations. Hermod Craig Gary
RE: svn commit: r500112 -/shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/resources/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?
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/resources/META-INF/tr-incubator-m1-SNAPSHOT-config.xml?view=markup
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 validators. Since you hav done something here,
could you send it to me and I'll look at it.
Hermod
RE: svn commit: r500112 -/shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/validator-rules.xml
From: [EMAIL PROTECTED] Hi Thanks Gary. I had missed that one in the cleanup. If I can find the time this weekend, I'm going to try cloning your archetype making one that focuses on trinidad. Then we can move on to other component libraries. I also made some hacks to your maven plugin to add the rendererType and include converters and validators. It is a hack and didn't feel right committing it :-) Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 3:39 AM To: commits@shale.apache.org Subject: 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 Author: gvanmatre Date: Thu Jan 25 18:38:49 2007 New Revision: 500112 URL: http://svn.apache.org/viewvc?view=revrev=500112 Log: Removed unused file (SHALE-391). Removed: shale/sandbox/maven/archetypes/shale-clay-starter-archetype/src/main/resources/a rchetype-resources/src/main/webapp/WEB-INF/validator-rules.xml * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: Clay, Tomahawk and jscookmenu
Hi We could do this in two phases: Phase 1: Adding in the rendererType as an attribute to the 1.4 version (curent) Phase 2 : Altering TldToClayconfig to generate annotated Java files for version 1.1.0 (I take it that will be the Java5 version) For phase 2 we will need to discuss further to define what TldToClayconfig should generate. Sounds like a good plan. The rendererType should help today with the tomahawk support. Hermod Gary
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. The second approach would be the best way to handle this. The problem with the first solution is that we define converters, validators and listeners as top-level XML components. The rendererType would just be clutter as a component attribute for anything but a component - the same as the facetName and id attributes. I hindsight, these odd-ball component attributes should have been placed in the attributes container. We might as well add the descriptions in the TLD to the Clay config too? On a tangent, I would like to refactor the beans that hold this information into interfaces and implementations. This discussion belongs in another thread but if Clay is given a GA grade with 1.0.4, I'd like to start moving the Clay trunk to depend on Java 1.5 and target JSF 1.2. In order to support all of the JSF 1.2 features, we will need to commit to the new API's. If we are locked into 1.5, we can look at annotations as our core metadata. If this idea shakes out with the list, I'll need some help (hint, hint ;-). Your TldToClayconfig plugin could be altered to generate Java source files with annotations too? These are just some of my ideas. I'd like to here from others about the direction they would like to see Clay go... Hermod Gary
Re: ApacheCon (was: Release ...)
From: Sean Schofield [EMAIL PROTECTED] I meant registration. I *really* wanted to present a talk but that would probably stress my already busy schedule to the breaking point. My idea for a talk would be to show how you can use various open source technologies (Shale, MyFaces, Spring and Hibernate) together to achieve some elegant and practical real worlds solutions. Basically show some best practices and possible ways to solve various problems one is likely to encounter. You could make a three full day course about those technologies used together and have to cut it short :-) Sounds like a great book. Anyways it seems we are a ways off from the registration period so I'll sit tight. I doubt I'll make it but there is always hope. Sean Gary On 1/9/07, Craig McClanahan wrote: On 1/8/07, Sean Schofield wrote: Anyone know when the signup is? You mean signup for papers, or for registering? The closing date for papers is Jan 15, but I don't know when the attendance registration will open. Sean Craig On 1/5/07, Craig McClanahan wrote: On 1/4/07, Rahul Akolkar wrote: On 1/4/07, Sean Schofield wrote: Thanks to Rahul for all the grunt work to pull this release together! +1 for that sentiment! Sorry I haven't been much help lately. I'm just getting my business off the ground these days so I've been tied up with that and some family stuff. I will be following along the best I can for the next couple of months! (And I will see some of you in Amsterdam) No such sorries are ever needed, IMO. Talking of Amsterdam, anyone else going? Any Shale sessions planned? I have been thinking about a piece on dialogs (and maybe other things), but have made no effort towards anything ApacheCon yet. I've submitted repeats on the two Shale sessions that Gary and I collaborated on for ApacheCon US ... a basic Shale session plus one on Shale+JPA. It would be great to see something else happen too, since the call for papers is still open for another couple weeks. The only negative for me is this is the week before JavaOne (always the madhouse activity peak of my yearly schedule). Oh well, I can always sleep in June :-). -Rahul Sean Craig
Re: [v1.0.4] Release notes (clay improvements etc.)
From: Rahul Akolkar [EMAIL PROTECTED] I'm done with changes to the release notes for now (commits@ list seems to have a lag right now). Please jump in and improve them. I have left one FIXME for any notable Clay changes that we may want to list as was done for 1.0.3 (Gary?), but anything else worth mentioning should go in section 3 and 4 as well. TIA. I'm snowed in for the rest of the year so I'll have some time to work on this today. However, I have a FedEx box ready to send my laptop into the shop. When the sucker gets overheated it just powers off. I might have to sit in the 6 foot snow pile outside my house to keep her cool :-). -Rahul Gary
Re: [v1.0.4] Release notes (clay improvements etc.)
From: Rahul Akolkar [EMAIL PROTECTED] On 12/29/06, Gary VanMatre wrote: From: Rahul Akolkar I'm done with changes to the release notes for now (commits@ list seems to have a lag right now). Please jump in and improve them. I have left one FIXME for any notable Clay changes that we may want to list as was done for 1.0.3 (Gary?), but anything else worth mentioning should go in section 3 and 4 as well. TIA. I'd like to mentions SHALE-324 in there but it doesn't pertain to the release artifacts. We haven't talked about how or if we are going to release the tools. I should have spoken up earlier. What do you think? I'm snowed in for the rest of the year so I'll have some time to work on this today. Thanks. However, I have a FedEx box ready to send my laptop into the shop. When the sucker gets overheated it just powers off. I might have to sit in the 6 foot snow pile outside my house to keep her cool :-). Yeah, those things can do more damage than shutting off these days ... That's what I'm afraid of. I can cause a power off by just running a bios check. I sure hope they take good care of her. no snow yet in the big apple, it was strange to have multiple rounds of golf a week till late December :-) Sounds nice but I love the snow. We don't get as much of it as you would think here in Denver. We are having one of those freakish back-to-back weeks of blizzards (not the QD kind). -Rahul Gary -Rahul Gary
Re: Test Framework Contribution
From: Dennis Byrne [EMAIL PROTECTED] I wrote an abstract test [1] that can marshal any number of TLDs and verify the following - are there setters on each tag handler for each TLD tag attribute? - are all tag handlers present in the classpath? - are there any duplicate tags? - are there any duplicate tag attributes? Concrete subclasses handle TLD paths, like this [2]. I feel this will help us put an end to a seriously pesky class of bugs on the MyFaces project. Does anyone here think this is a good candidate for the Shale test framework. ? +1 Seems like a good fit to me. There are two dependencies [3,4] and I'll write some documentation. Craig has worked hard to eliminate the common beanutils dependencies but that dependency could be removed with a few helper methods. I have to admit, I am a little bitter your team did not accept my very excellent submission to the logo contest [5], but I'd rather see this code placed where others can use it :) Indeed, it is hard to find art that captures the spirit(s) of two communities better than your submission. Dennis Byrne Gary [1] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apach e/myfaces/test/AbstractTagLibTestCase.java?revision=491051view=markup [2] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apach e/myfaces/test/MyFacesTagLibTestCase.java?revision=491051view=markup [3] http://maven-taglib.sourceforge.net/ [4] http://jakarta.apache.org/commons/beanutils/ [5] http://shale.apache.org/logo-contest.html
Re: [SHALE-379] Update to api-stability page not showing?
From: Craig McClanahan [EMAIL PROTECTED] On 12/29/06, Gary VanMatre wrote: From: Craig McClanahan I updated a big first pass fixup on the api-stability page (source is framework/src/site/xdoc/api-stability.xml), but the website did not get regenerated and republished as it usually does. Is there something we need to do to trigger that? In the mean time, please review the source file for content. A particular question for Gary is whether we want to mark any of the org.apache.shale.clay APIs as being designed for direct use by an application developer in a webapp, or if that is all supposed to be behind the scenes and all you are doing is using the components themselves in your view. I think your right-on to say that the clay component and metadata sources are the strongest extension points. I've thought about making interfaces of the config beans so that it would be easier to define alternate sources for the metadata used to build the subtree. This is an area that the JSF spec doesn't address and I wonder if it will be covered in JSF 2? I wouldn't be surprised if we see some templating extension that is similar to facelets which might be another option for Clay to support. It seems likely to me that JSF 2 will deal with non-JSP view handlers in some fashion, but that's ultimately up to the EG to decide -- and a JSR has not even been filed yet. It might be best to keep the published API based at a Component that is loosely defined by various metadata sources. Please add the org.apache.shale.clay package to the public API list. Well, I would ... but there are no classes or interfaces directly in this package. Oh, right... How about org.apache.shale.clay.component. There are two components here. What I did for the other packages was identify those that had classes or interfaces you'd expect to import into the Java code in a webapp. Is there anything like that in Clay? The only thing I can see in the sample apps is the use of org.apache.shale.util.Messages from shale-core. I suppose that you might import these components if you used binding to the backing bean but maybe that's assumed with any JSF component. Craig Gary Craig
Shale Tiger Annotations with large projects
The Shale Tiger library uses annotations to declare meta-data that in some cases would have been configured using a central XML configuration file. Shale gathers the annotation data at the startup of the application by loading the classes. Some have expressed concern that loading the classes at startup will not scale well with very large web applications. I was wondering if Shale should provide a maven plug-in that scans the classes before packaging. The Mojo could generate a faces configuration file that is added to the web project before packaging. Or, maybe the plug-in could generate a configuration file that listed the classes containing annotations to process. This would be similar to the JPA out-of-container requirement for entity beans. Any thoughts? Gary
Re: Shale Tiger Annotations with large projects
From: Mario Ivankovits [EMAIL PROTECTED] Hi! Try out the current support by setting context init parameter org.apache.shale.tiger.SCAN_PACKAGES. The value is a comma delimited list of individual JAR filenames (shale-tiger.jar) and package prefixes ( org.apache.shale.foo). As far as I remember I just implemented the package prefix scan as this is the most powerful thing. And yes, this *really* needs to be documented :-). Yea - I know. I'll try to find some spare minutes to submit a patch with a short documentation. @Gary: See [1] to get a quick overview about the configuration (though, ignore the jar part). There you'll also find a tool which helps you to figure out which packages to configure in SCAN_PACKAGES by scanning the classpath, but if you are the developer of an application it shouldn't be that that hard to figure out manually ;-) Ah, I remember that dialog now. Good job with that patch. Ciao, Mario Gary [1] http://issues.apache.org/struts/browse/SHALE-301
Re: svn commit: r479836 - in /shale/framework/trunk/shale-validator/src: main/java/org/apache/shale/validator/converter/ main/java/org/apache/shale/validator/util/ main/java/org/apache/shale/validator
From: [EMAIL PROTECTED]
To: commits@shale.apache.org
Sent: Monday, November 27, 2006 6:17 PM
Subject: svn commit: r479836 - in
/shale/framework/trunk/shale-validator/src:
main/java/org/apache/shale/validator/converter/
main/java/org/apache/shale/validator/util/
main/java/org/apache/shale/validator/validator/ main/resources/META-INF/
main/resources/org/...
Author: craigmcc
Date: Mon Nov 27 17:17:42 2006
New Revision: 479836
URL: http://svn.apache.org/viewvc?view=revrev=479836
Log:
Upon further review, the original strategy (for SHALE-340) of writing an
individual Validator for each Commons Validator validator, but still going
through the general purpose lookup mechanisms, is more work than needed.
We know exactly what Commons Validator instance we want to use, so lets
just use it directly.
The only issue I see with this solution is that you can not override
validation messages.
Instead of creating one generic mechanism, you rewrite code specific for
each validator. In the
end you will end up with a bunch of wrapper code versus common code.
At the same time, leverage the fact that Commons Validator validators can
do
formatting as well to provide a JSF Converter that goes along with the
validator. Still only done Integer so far, and not dealt with the client
side aspects yet ... that will come next.
SHALE-342
Added:
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/AbstractConverter.java
(with props)
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/IntegerConverter.java
(with props)
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/package.html
(with props)
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/util/AbstractUtilities.java
(with props)
shale/framework/trunk/shale-validator/src/test/java/org/apache/shale/validator/converter/
Modified:
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/validator/AbstractValidator.java
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/validator/IntegerValidator.java
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/validator/package.html
shale/framework/trunk/shale-validator/src/main/resources/META-INF/faces-config.xml
shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/resources/Bundle.properties
shale/framework/trunk/shale-validator/src/test/java/org/apache/shale/validator/validator/IntegerValidatorTestCase.java
Added:
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/AbstractConverter.java
URL:
http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/AbstractConverter.java?view=autorev=479836
==
---
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/AbstractConverter.java
(added)
+++
shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/converter/AbstractConverter.java
Mon Nov 27 17:17:42 2006
@@ -0,0 +1,81 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version
2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.shale.validator.converter;
+
+import javax.faces.component.UIComponent;
+import javax.faces.context.FacesContext;
+import javax.faces.convert.Converter;
+import org.apache.shale.validator.util.AbstractUtilities;
+
+/**
+ * pAbstract base class for converters that use Apache Commons
Validator
+ * as their foundation./p
+ */
+public abstract class AbstractConverter extends AbstractUtilities
+ implements Converter {
+
+
+//
Constructors
+
+
+// --
Properties
+
+
+// --- Converter
Methods
+
+
+/**
+ *
Re: Validators should validate *submitted* values
From: Craig McClanahan [EMAIL PROTECTED] While reviewing the work done so far on the Shale Validator integration in preparation for the changes described in SHALE-340, I ran into an issue that is noted in the comments on SHALE-36 but needs to be explicitly decided. If you have explicitly defined a converter (or JSF can do it for you implicitly because the value is bound to a bean property with a known type), then the value that is passed in to the validate() method will already have been converted. This will lead to problems when calling methods like GenericValidator.isInt() for an argument being validated as an integer, which assumes the incoming value is a String. What I propose is that the validate() methods in shale-validator should ignore the value parameter to the validate() method. Instead, they should cast the UIComponent to a n EditableValueHolder, and then call getSubmittedValue() on that to get the value to be validated. This seems much more in line with the assumptions Commons Validator makes (it is validating strings). The potential cost of this is that the format validation done here is basically wasted if a converter has already been applied, but it allows the validation logic to not worry about this kind of thing. Thoughts? If we use the submitted value, we are assuming that the converter is only handling simple data type conversion. The converter might be stripping out $ or ,. That's why it uses the converted type that converts it to a string and then to the target type. I guess we could assume that they are not doing anything tricky with type conversion and use the submitted value but that's why that decision was made. Craig Gary
Re: [jira] Commented: (SHALE-340) Catch-all for general improvements and documentation for shale-validator
From: Craig McClanahan (JIRA) [EMAIL PROTECTED] [ http://issues.apache.org/struts/browse/SHALE-340?page=comments#action_38839 ] Craig McClanahan commented on SHALE-340: Looking further into the way that shale-validator is implemented today, I'm considering being (quite a bit) more aggressive -- I'd like to improve things at both the API level and the tag level, while we still have a chance before a GA release. In particular, here's what I'm thinking: * o.a.c.v.CommonsValidator exposes a bunch of public and protected methods that really belong in helper classes instead of here (in a javax.faces.validator.Validator implementation). * Need to implement a bunch of new validators that Commons Validator 1.3 supports but we do not. * For better usability (and integration in IDEs), provide individual validator implementations (and corresponding JSP tags if you use JSP as your view) for the standard Commons Validator validations. While doing so, look at choosing a clever tag library prefix so that the tag names can be shortened (perhaps instead of ). * At the tag level, look at combining the foo and fooRange validations into a single validator (e.g.: [max=value]/) from the user perspective. * Still support the old-style generic validator, for extensibly plugging in custom validators, but discourage its use for the standard ones. * Look for ways to eliminate the need to use explicitly. You should be able to get that for free. * While doing the above, provide robust abstract base classes to make it really easy for custom Commons Validator validations, and corresponding JSF validator tags. It should be easy to maintain the existing tags for backwards compatibility, but I think we can avoid being constrained by compatibility concerns at the Java API level. But accomplishing the above will go a *long* ways towards satisfying a general JSF desire for client plus server side validation support in a very usable (for manual and IDE-assisted users) way. Thoughts? I think these are all good ideas. Here are obviously issues with the clutter that is distracting from the features. Having a validator subclass for each type of rule would be more of a JSF way. Moving the validator logic to helper classes would also allow people to use it in the validator property binding callbacks. And, the script component could be automatically added using the renderer decorator approach on the form renderer. The solution for evaluation of client side validator value binding expressions in a UIData subclass. I was not happy with the extra validator XML form use to describe the formal and actual parameters and the message parameters. I wanted to use as much of the existing shale and commons implementation. If we created wrapper callbacks like in struts, we wouldn't need this extra information but it's not as configurable. At the time, no one else had additional ideas so I just went with it. Gary
Re: abstract AbstractViewController ?
From: Matthias Wessendorf [EMAIL PROTECTED] Hi, I just looked at the source of shale after a while; however the AbstractVC is not abstract; why ? Ha! That's like asking for a diet soda that has 100 callories. Should we change that ? I bet it was just a mistake. Go for it! Thanks, Matthias Gary -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r466600 - in /shale/framework/trunk/shale-test/src: main/java/org/apache/shale/test/el/ main/java/org/apache/shale/test/mock/ test/java/org/apache/shale/test/el/ test/java/org/apache/s
From: Craig McClanahan [EMAIL PROTECTED]
On 10/21/06, [EMAIL PROTECTED] wrote:
Author: gvanmatre
Date: Sat Oct 21 15:46:02 2006
New Revision: 466600
URL: http://svn.apache.org/viewvc?view=revrev=466600
Log:
Added better mock value binding expression support for scoped attribute
names that contain dotted values.
Interesting approach. Shouldn't we do something simpler to the
1.1-compatible ValueBinding and MethodBinding implementations in shale-test?
I ran into this limitation in a Clay test case. I wanted to place an attribute
in request scope using a dotted id.
#{requestScope['org.apache.shale.clay.xmlns']}
The mock implementation did not support the parsing. So, I ended up using a
simple key name rather than choosing to not implement a test case. This seems
like a commonly need feature even in JSF 1.1. I hate having to choose and
implementation based on limitations of testing so I added ten or so more lines
of code.
Craig
Gary
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
From: Rahul Akolkar [EMAIL PROTECTED] On 10/18/06, [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Wed Oct 18 16:37:05 2006 New Revision: 465422 URL: http://svn.apache.org/viewvc?view=revrev=465422 Log: This is a fix for the Clay implicit anchored tag mapping that was not assigning the href to the component's value attribute. It was reported by Torsten Krah (SHALE-313). Added: shale/framework/trunk/shale-clay/src/test/java/org/apache/shale/clay/config/Impl icitMappingTestCase.java (with props) shale/framework/trunk/shale-clay/src/test/resources/org/apache/shale/clay/config /implicit.html (with props) Gary, can you please add ASLv2 headers to new files? Don't worry about these two -- as part of my todo list, I'm planning on adding them to any missing source files (my guess would be we're missing these in quite a few files, probably all in the test and site docs categories. I plan to drop in the headers when I get a chance since these tend to get packaged in the source distributions -- unless these are objections to doing so). I did add svn:eol-style of native. What other options do we need for test cases and html resources? I figured that svn:keywords wouldn't apply to these types of resources? -Rahul Gary
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
From: Rahul Akolkar [EMAIL PROTECTED] On 10/20/06, Gary VanMatre wrote: From: Rahul Akolkar On 10/18/06, [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Wed Oct 18 16:37:05 2006 New Revision: 465422 URL: http://svn.apache.org/viewvc?view=revrev=465422 Log: This is a fix for the Clay implicit anchored tag mapping that was not assigning the href to the component's value attribute. It was reported by Torsten Krah (SHALE-313). Added: shale/framework/trunk/shale-clay/src/test/java/org/apache/shale/clay/config/Impl icitMappingTestCase.java (with props) shale/framework/trunk/shale-clay/src/test/resources/org/apache/shale/clay/config /implicit.html (with props) Gary, can you please add ASLv2 headers to new files? Don't worry about these two -- as part of my todo list, I'm planning on adding them to any missing source files (my guess would be we're missing these in quite a few files, probably all in the test and site docs categories. I plan to drop in the headers when I get a chance since these tend to get packaged in the source distributions -- unless these are objections to doing so). I did add svn:eol-style of native. What other options do we need for test cases and html resources? I figured that svn:keywords wouldn't apply to these types of resources? I was actually mentioning the missing ASF license header (that should be at the top of source files) in that comment. As far as svn props are concerned, I add keywords to (java) test cases and html resources (I think we should), but the comment above isn't about svn props. -Rahul Cool, I'll add it to the java source but adding it to the html resource would mess with what is being tested. -Rahul Gary
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
From: Rahul Akolkar [EMAIL PROTECTED] On 10/20/06, Gary VanMatre wrote: From: Rahul Akolkar I was actually mentioning the missing ASF license header (that should be at the top of source files) in that comment. As far as svn props are concerned, I add keywords to (java) test cases and html resources (I think we should), but the comment above isn't about svn props. -Rahul Cool, I'll add it to the java source but adding it to the html resource would mess with what is being tested. Thanks. On the html resources front, I'd have thought we can drop the license in a html comment between the clay:remove start and end comments at the beginning and not affect what is being tested at all? I can do that (though won't be immediate), if its OK with you and others. The problem in doing that for the test cases is that we are actually testing parsing the document. Since Clay has it's own markup parser that works for html and xml documents, there are tests to make sure the parser will handle comments. I'm not against adding the text to the templates within the remove blocks since it will actually make the test more extensive but it does broaden the scope of the test. The clay:remove is a new feature that was added in the 1.0.4-SNAPSHOT. We might as well make use of it. -Rahul Gary -Rahul Gary
Re: Shale home page
From: David Geary [EMAIL PROTECTED] 2006/9/25, Wendy Smoak : Someone on IRC brought up a good point about the Shale home page: We don't say what Shale *is* until 1/3 of the way down the page. I think the information in the paragraph that starts Thus, Shale is... belongs up at the top of the page. Thoughts? Volunteers to fix it? :) Actually, IMO, that paragraph and the rest of the Background section are dated now that we've cut ties with Struts. We could probably do with a new introduction altogether. And a snazzy new logo, dammit. +1 on that note! david -- Wendy
Re: FindBugs reports (was: Re: svn commit: r449524)
From: Wendy Smoak [EMAIL PROTECTED] On 9/24/06, [EMAIL PROTECTED] wrote: Author: wsmoak Date: Sun Sep 24 16:43:11 2006 New Revision: 449524 URL: http://svn.apache.org/viewvc?view=revrev=449524 Log: Add the FindBugs plugin for reporting. See http://mojo.codehaus.org/findbugs-maven-plugin/howto.html for configuration. I added FindBugs to the reporting section of the framework pom. Here are some initial reports with the default configuration: http://shale.apache.org/shale-core/findbugs.html http://shale.apache.org/shale-clay/findbugs.html http://shale.apache.org/shale-tiger/findbugs.html You can find the link under Project Reports for each module. Thanks Wendy. -- Wendy
Re: Shale-related Tiles 2 issue
From: Wendy Smoak [EMAIL PROTECTED]
On 9/24/06, Gary VanMatre wrote:
Hey Wendy, this looks like the classic JSF 1.1 problem with JSP that will
be fixed in JSF 1.2.
That's what I thought. :)
It's also a good practice to wrap an included fragments in a subview tag.
The
subview is a naming container that will allow the same fragment containing
input
widgets to be included several times in the same page.
This came up recently on [EMAIL PROTECTED] [1] and Dick Starr reported that
the was working with or without a subview tag. I'm not
sure how that differs from though.
I doubt he's including the header text more than once... exactly when
is the subview tag necessary, and what does it do?
Let's say you had two address jsp fragments for street and mailing address.
Both fragments contain the same widgets just bound to different properties in
the backing bean. You want to include both into the same form.
streetAddress.jsp
h:inputText id=address1 value=#{streetAddress.address1}/
...
mailingAddress.jsp
h:inputText id=address1 value=#{mailingAddress.address1}/
The html input elements will be named using the id attribute of the inputText
tag. Without a subview tag, there would be two html elements with the same
name. The subview component is a naming container that will force the id of
the subview into the id of all contained elements. This is called the
components client id. The h:form component is also a naming container.
If each included jsp was nested in a subview in the same form, the id and name
of the two input widgets might looks something like this:
name=form1:streetSubview:address1
name=form1:mailingSubview:address1
You might say, big deal. Just name the widgets in address fragment uniquely.
Well, if you use Clay, you wouldn't need to create two address templates. You
can use Clay's symbols to reuse the same template by changing the value binding
expression.
h:inputText id=address1 value=[EMAIL PROTECTED]/
The symbol @managed-bean-name could be substitued with streetAddress or
mailingAddress.
Gary
[1]
http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.htm
l#a6288731
Thanks,
Wendy
Re: [dialog] Browser navigation buttons
From: Craig McClanahan [EMAIL PROTECTED] On 8/28/06, Rahul Akolkar wrote: Thinking aloud about the mandatory feature 11 on the DialogManagerFeature wiki page [1]. Just noted that SWF has some of the same limitations, and its possible to drop traces into the browser atleast with the continuation configurations I was looking at. In some previous experiments [2] as part of SHALE-61 [3], the approach taken was splitting the dialog's per turn processing into two bits: (a) Aligning the server-side state machine, if necessary (b) Once aligned, triggering the postback event on it There are at least some use cases where re-syncing the server side state is not necessary. For example, a simple wizard dialog that just collects data won't necsesarliy suffer if the same data gets submitted twice. It's scenarios where things like database updates have already taken place (i.e. what might happen in a typical finish state), where you'd want to deal differently with syncing, even in the same dialog. I guess a fundamental question here is, can we actually recognize that these events have occurred? If so, we could do something like trigger server side events that would notify the dialog context, and it could make its own adjustments (perhaps, for example, maintaining an undo log that gets triggered when you press the back arrow). At the same time, the dialog context could recognize special events that mean don't make any further changes -- although, that is going to get tricky to implement if the view states inside the dialog has input fields bound to properties on the context data object. It'd probably need to cache away the values that were actually used, and stop paying attention to updated input fields. As long as the state machine is residing on the other side of the network boundary, it seems a bit unclear whether (a) can at all be avoided. The effort for the developer, however, can be reduced if (a) is transparent to the developer, which was the exercise in [2] where the state machine was decorated with some additional transitions which realigned the dialog based on the view that posted back. I hear JSF 1.2 alleviates some browser button issue, is it possible for anyone to elaborate on that? The improvements were primarily to match up the correct component tree, in the face of the user pressing navigation buttons, when state is saved on the server side. This part already worked for client side state saving, because the saved state would get resubmitted along with the rest of the form. I think this only helps our situation, though, if the dialog state were also saved and restored in the component tree itself (instead of just saving a dialog identifier). I have concerns about what this could do to the size of the serialized component tree for client side state saving -- but perhaps we could figure out how to make this conditional to avoid that potential problem. Saving and restoring the dialog context to the views state, would might solve a couple of issues (undo state and restoring the context to a previous state). I think myfaces has a component to do that but I agree that the client state is not the right place for a large chunk of data. However, I really like what you have done with the dialog id. You've tucked it away under the view root. In this case, this state is saved with the view but it's only a simple integer. Maybe a similar concept would work for tracking the dialog context. What if the dialog manager tracked the context with a sequence id. The sequence id, a simple integer, could be saved in the view state with the dialog id. Then when the dialog is restored, it could use the sequence and id to resume execution. If you wanted a undo, type of processing, the sequence id might be used as keys into a working db table. Gary The additional concern, ofcourse, is whether (a) is always the right thing to do i.e. whether the side-effects of progressing the dialog are actually reversible / overwriteable (whether the underlying datamodel can be rolled back) -- what should be done if it can't, and what should be the authoring best practice (some dialog tokens etc.) -Rahul [1] http://wiki.apache.org/shale/DialogManagerFeature [2] http://people.apache.org/~rahul/shale/align-dialog/ [3] https://issues.apache.org/struts/browse/SHALE-61 Craig
Re: [dialog] Browser navigation buttons
From: Craig McClanahan [EMAIL PROTECTED] On 9/16/06, Gary VanMatre wrote: From: Craig McClanahan On 8/28/06, Rahul Akolkar wrote: Thinking aloud about the mandatory feature 11 on the DialogManagerFeature wiki page [1]. Just noted that SWF has some of the same limitations, and its possible to drop traces into the browser atleast with the continuation configurations I was looking at. In some previous experiments [2] as part of SHALE-61 [3], the approach taken was splitting the dialog's per turn processing into two bits: (a) Aligning the server-side state machine, if necessary (b) Once aligned, triggering the postback event on it There are at least some use cases where re-syncing the server side state is not necessary. For example, a simple wizard dialog that just collects data won't necsesarliy suffer if the same data gets submitted twice. It's scenarios where things like database updates have already taken place ( i.e. what might happen in a typical finish state), where you'd want to deal differently with syncing, even in the same dialog. I guess a fundamental question here is, can we actually recognize that these events have occurred? If so, we could do something like trigger server side events that would notify the dialog context, and it could make its own adjustments (perhaps, for example, maintaining an undo log that gets triggered when you press the back arrow). At the same time, the dialog context could recognize special events that mean don't make any further changes -- although, that is going to get tricky to implement if the view states inside the dialog has input fields bound to properties on the context data object. It'd probably need to cache away the values that were actually used, and stop paying attention to updated input fields. As long as the state machine is residing on the other side of the network boundary, it seems a bit unclear whether (a) can at all be avoided. The effort for the developer, however, can be reduced if (a) is transparent to the developer, which was the exercise in [2] where the state machine was decorated with some additional transitions which realigned the dialog based on the view that posted back. I hear JSF 1.2 alleviates some browser button issue, is it possible for anyone to elaborate on that? The improvements were primarily to match up the correct component tree, in the face of the user pressing navigation buttons, when state is saved on the server side. This part already worked for client side state saving, because the saved state would get resubmitted along with the rest of the form. I think this only helps our situation, though, if the dialog state were also saved and restored in the component tree itself (instead of just saving a dialog identifier). I have concerns about what this could do to the size of the serialized component tree for client side state saving -- but perhaps we could figure out how to make this conditional to avoid that potential problem. Saving and restoring the dialog context to the views state, would might solve a couple of issues (undo state and restoring the context to a previous state). I think myfaces has a component to do that but I agree that the client state is not the right place for a large chunk of data. However, I really like what you have done with the dialog id. You've tucked it away under the view root. In this case, this state is saved with the view but it's only a simple integer. Maybe a similar concept would work for tracking the dialog context. What if the dialog manager tracked the context with a sequence id. The sequence id, a simple integer, could be saved in the view state with the dialog id. Then when the dialog is restored, it could use the sequence and id to resume execution. Are you thinking about a generation number of the state of the context, that would increment each request? That could work if the server maintained a copy of each generation somehow, that you could go back to when the repeated request came in. Ya, that way the only state the view has to worry about is the generated number along with the dialog id. We could also use the renderer decorator trick that we are using for commons validator to inject a couple hidden attribute into the form for the generated number and the dialog id. In addition add the parameter to the outputLink? BTW, I'm going to take a try at moving commons valiator out of the core. I might need some help with the clean up. Does shale-commons-validator sound ok for the project under framework? On the other hand, there will be use cases where the application does *not* want to allow the user to simply redo a previous
Re: svn commit: r443256 - in /shale/framework/trunk: ./ shale-apps/ shale-clay/ shale-clay/src/test/java/org/apache/shale/clay/config/ shale-core/ shale-remoting/ shale-spring/ shale-test/ shale-tiger
From: [EMAIL PROTECTED] Author: craigmcc Date: Wed Sep 13 23:16:55 2006 New Revision: 443256 URL: http://svn.apache.org/viewvc?view=revrev=443256 Log: Implement a fairly massive refactoring of our Maven2 build dependencies, and (along the way) address the issues raised by SHALE-258 (although they are probably not completely covered yet). Highlights of the changes: * Dependencies to compile the Shale Framework libraries have been adjusted to always use the MyFaces API jar (it should not matter which implementation is used to compile against, because the signature tests in the TCK will ensure method signature compatibility). * Migrate as many dependency version numbers as possible into the section of the shale-parent POM, along with exclusions that avoid adding optional dependencies to the classpath. * Move the profile stuff about choosing MyFaces or the JSF RI into the shale-apps-parent POM, instead of shale-parent, since this now only affects webapps. * There is a wierd test failure on the shale-clay unit tests that I could not figure out, so I commented out those test cases for now. Gary, could you take a look at CommentTestCase? This test is building the component tree and rendering the output. The output is parsed and checked for an embed comment. Since the myfaces-impl is not a dependency, the renderers are not being loaded and no markup generated. I could create some mock renderers for this test. That would be much easier than starting a wrestling match with maven. Gary
Re: svn commit: r443457 - /shale/sandbox/shale-clay-jpa/src/main/java/org/apache/shale/clay/configjpa/services/impl/
From: [EMAIL PROTECTED] Author: rahul Date: Thu Sep 14 13:22:18 2006 New Revision: 443457 URL: http://svn.apache.org/viewvc?view=revrev=443457 Log: Add props to missing bits in r443202, hope you don't mind Gary ... Nope, Rock on! Gary
Re: Simplifying Framework Dependencies
From: Craig McClanahan [EMAIL PROTECTED] As Shale moves towards maturity, one of the usability issues on my mind is the set of dependencies that we currently mandate in shale-core and friends. I would like us to take a look at whether we can eliminate some or all of these dependencies, and therefore slim down the amount of code that must be included in a web application's WEB-INF/lib directory simply to use Shale features. A related aspect of this might be to divide shale-core into separate JARs for the discrete pieces of functionality one might wish to employ ... but the same issues will apply in those cases as well. One particular issue that will fall out of this discussion, of course, is how the framework should log its own messages ... my recommendation below might well engender enough discussion to need its own mail thread :-). Before getting into details, an important philosophical issue is that fact that we (today) tend to inherit a bunch of transitive dependencies from whichever JSF implementation you want to use (MyFaces or the JSF RI), and any attempt to eliminate direct dependencies on the same JARs seems useless. We have to remember, however, that JSF 1.2 is part of Java EE 5 and the typical usage pattern on an EE 5 server will be to *not* include a JSF implementation in the webapp. In a similar vein, it's pretty easy to configure something like Tomcat (or JBoss, or Jetty, or whatever) to include a JSF implementation in the parent class loader ... so we should be sensitive to developers who want to leverage such shared resources and minimize the payload that must be loaded into each individual WAR. At the moment, shale-core depends on the following external resources (I'm leaving specific version numbers out of the equation because they aren't relevant to the overall discussion): * Commons BeanUtils - Transitive dependency from Commons Digester - Cleanup code on application shutdown (can be modified to use reflection to do this optionally) - Also used directly in other modules * Commons Chain - Parsing chain-config.xml files for the application level filter * Commons Digester - Transitive dependency from JSF implementations - Used to parse configuration files in modules like shale-clay and for dialogs * Commons Logging - Transitive dependency from JSF implementations - Directly used all over the place * Commons Validator - Required if you use the validation tags (maybe separate into separate module?) * Jakarta ORO - Transitive dependency from Commons Validator I would propose the following initial steps to simplify our dependencies, and will create JIRA tasks for them after implied or explicit consensus is achieved: (1) Switch to using JDK 1.4 logging for all framework related logging - We require JDK 1.4 or later anyway, so this is always available - Shale's logging needs (on its own behalf) are very simple and require no special functionality - Using this does *not* prevent an application from using something else (such as Log4J) for its own logging purposes +1 (2) Eliminate direct BeanUtils dependencies - Replace by use of utility methods for property copying that are already available in shale-core - Need to implement standalone replacement in shale-test to avoid introducing new dependency - Do the BeanUtils cleanup functionality optionally, and via reflection, instead of directly + 1 You've already checked this one off the list right? (3) Split the validator related stuff into a new module, so you don't need to inherit its dependencies if you only need shale-core - This module will inherit most of its dependencies transitively +1 The validator has hooks into the core view handler. It is registering a RenderKitFactory wrapper. We could do this from the faces-config but would risk some other library doing the same. (4) When/if the updated dialog2 stuff is migrated out of the sandbox, keep as separate modules - Goal is to minimize size of shale-core (maybe even eliminate if everything gets factored into smaller modules?) (5) Consider splitting out the view controller hierarchy into a separate module This might be a good plan if we take a try at JSR 299. Ryan Wynn might like that option too :-) - Same goal as (4) (6) Evaluate alternatives for configuration file parsing, in conjunction with potentially generic support for reloadable config files (there's machinery for this already in shale-clay). We could pull the this out of clay but I would also be interested in other ideas. The file watch dog in clay relies on a commons chain filter command. I could pull it out and we could then make a decision as to if it will work in the other scenarios. - This is probably the hardest nut to crack in the dependencies area. Thoughts? Craig Gary
Re: [dialog] Basic button functionality
From: Sean Schofield [EMAIL PROTECTED] No I'm not proposing we deal with generating HTML rendering business as far as dialogs are concerned. [I'll post a more detailed explanation on the shale dev list where that belongs.] This might not be a bad idea. The struts synchronization token is wired to the html:form and html:link jsp tags. They propagates forward a token that represents a context. A unique token could be used to identify simultaneous dialogs per session. We could inject this token using the same method that we add javascript to the commands onclick event for commons validator. This doesn't work with components that hijack the response writer for more than their own renderering. Tomahawk as one of these kind of components and I wouldn't doubt if Trinidad does too. Gary @Adam: If you're not already subscribed to shale dev we'd love to have you over there. Specifically, we could benefit from your insight regarding dialogs. @Everyone Else: This goes for you too. If you're using JSF you'll want to check out Shale which just builds on JSF and provides a lot of cool stuff missing from the spec. Sean On 8/24/06, Gary VanMatre wrote: From: Adam Winer Wrong list, sure, but since you opened up the can of worms... Is Shale really planning on getting into the HTML-rendering business? What do you mean by HTML-rendering business? We have custom components that do rendering. Clay has been around better than a year now and provides rich view composition using various templating options. Clay is a component in of itself that simple builds a subtree of components using a mechanism other than JSP tags. The clay component renders it children. When using full html (tapestry like) views or full xml (tiles like) views, the clay component is the only child under the view root so it pretty much renderers the full page. -- Adam Gary
Re: [dialog] Get rid of subdialogs
On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote:
I agree that, if we keep the concept of subdialogs around, mechanisms
for
dealing with this are important. From the perspective of a subdialog, you
should be able to pull data out of the parent dialog's context
transparently (WebWork/XWork do this with their action context method).
And, we would want to provide a way for a subdialog to push data u (at
least) a level as well.
What if we used dependency injection for the state object? Instead of
relying on this hard-coded #{dialog.data} business you could just have
a setData method that could be injected with an existing bean. IIRC
the current mechanism is that you provide your own data object by
calling setData from one of your dialog states.
I think it would be cool if you could have something like
dialog name=Edit Profile start=Setup context=#{user}
where #{user} is a session-scoped bean defined in your faces-config
file. We could just make it a policy to clean it up after the dialog
ends (if that's your desire.) We could even make the cleanup optional
and only dump the context data if the bean implements a DialogCleanup
interface.
I think this also solves the problem of storing states for multiple
simultaneous dialogs that have not yet finished.
I don't see how this handles starting two instances of the same dialog at
once (say, in two different windows), unless we can design some magic
variable resolver that picks the right one somehow.
That's what I was thinking. The variable resolver could key off a reserved
variable name DIALOG or something.
It could search for the dialog token and use that to identify the dialog
context.
Use a default if the token doesn't exist in some scope. This assumes two
reserved EL names.
Craig
Gary
Re: [VOTE] Shale Version 1.0.3 Release
From: Craig McClanahan [EMAIL PROTECTED] (3) Vote Please review these artifacts, and test their signatures, then vote on whether we should release them as Apache Shale version 1.0.3. If it passes we'll hold a quality vote later on. [ ] +1 (Binding) for PMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released It looks like there is a bug in the shale-mailreader on the edit profile page. The delete and edit buttons are not working for the hosts grid. Might be a bad navigation rule. I'll try to check that out but that is not a reflection of the libraries. +1 Gary My vote is +1 (Binding) Craig McClanahan
Re: [jira] Resolved: (SHALE-24) [Shale] No clay component configuration for MyFaces Tomahawk
From: Mike Kienenberger [EMAIL PROTECTED]
It's probably worth noting that the infrastructure for native facelets
support in Tomahawk is being discussed right now on the MyFaces lists.
This would be a great time to jump in and get Clay support set up as
well. I don't think we have any myfaces committers who are using
Clay, so we'll definitely need assistance for this.
Humm, I would be willing to start a project in the shale sandbox that was
targeted at converting the tomahawk component examples into jsp/xml and clay
templates. Clay supports html namespaces too. This is a new feature and would
be a good method of working out the issues.
I don't have the strength to try to do this on the myfaces JIRA.
On 8/3/06, Craig McClanahan wrote:
On 8/2/06, Gary VanMatre (JIRA) wrote:
[ http://issues.apache.org/struts/browse/SHALE-24?page=all ]
Gary VanMatre resolved SHALE-24.
Fix Version/s: 1.0.3
Resolution: Fixed
This is a resolution for SHALE-24. We have the people here that are
interested in doing the work. Ryan Wynn has contributed two versions of
the
clay config for the tomahawk 1.1.1 and 1.1.3 releases. These will not be
loaded by default by can be included using an init parameter.
I am absolutely delighted that Ryan was willing to do this work. But, my
question is ... why is it don e here instead of inside Tomahawk? If a JSF
component library wants to claim compatibility with a JSF view technology
(Clay or Facelets), it seems reasonable that the library would be the place
to manage this sort of thing ... that way, they could declare an optional
dependence on a particular version of Clay, or Facelets, and provide the
appropriate metadata configuration for each release of the components.
Expecting the framework provider (Clay or Facelets) to keep up with each
library isn't scalable in the long run.
Maybe in the long run Shale should not host these configurations but it's a
short term strategy to build momentum.
The RI only demands that a component library support JSP. IMO, if Clay can not
capture the attention of the component providers, we can't expect them to
invest the time in providing native support for something that the RI doesn't
embrace.
Craig
Gary
Re: JSR-299 (Web Beans) Implementation In Shale?
From: Craig McClanahan [EMAIL PROTECTED] I recently spoke with Gavin King (spec lead for JSR-299) about this JSR. In addition to getting his agreement on both Matthias and James to be on the EG, we talked a bit about their (Red Hat's) plans for the RI and TCK. Their thinking is that the RI and TCK would be developed by Red Hat themselves (since they are the company responsible for providing it) under some reasonable open source license ... but Gavin would actually like it if there was a second implementation being developed at the same time. That kind of thing goes a long way towards catching design limitations and/or ambiguities in the spec as it's being developed. So, I've got a question for us ... would we be interested (now or later) in building *a* compatible implementation of this JSR, even though it wouldn't be *the* RI? Instead, it would be a feature of Shale in addition to all the other stuff we do. I'm pretty intrigued by this, and the ideas that JSR-299 wants to deal with fit pretty nicely with what we've already started. It would make sense for us to have this kind of functionality available inside Shale. If we go this way, this seems like a good candidate for the sandbox during development (since we wouldn't be able to ship a finished release of it until the spec goes final). What do you think? Are we interested in putting this on our roadmap? (And following up +1s with code? :-) +1 That would be a great addition. How about shale composites :-) Craig PS: Another JSR we should keep an eye on is 303 (common annotations for validation) that Jason recently submitted. If it gets accepted, we'll likely want to support the result in Shale as well. Outstanding!
Re: Unit testing JPA in sandbox
I was looking at adding some junit test cases for a maven build mocking the shale mail reader JPA library in the sandbox. I'm using the a transaction type of RESOURCE_LOCAL so the test can be ran under JavaSE. The problem I'm seeing is that the test needs to load the persistence.xml from the META-INF of the target jar. It can't seem to find it under the project's target. I'm seeing a error message that the default provider can't be found. What am I missing here? Any ideas? It seems to work with the latest toplink archive. http://www.oracle.com/technology/products/ias/toplink/JPA/index.html
