RE: The pdfExport component released ;)
Hi From the sample code it seems that your component will just put the content of one table into the PDF. For the PDF-export it would make sense to also allow - multiple tables - forms - even complete views to be exportable. Would this require a big refactoring to be possible? regards Alexander From: Hazem Saleh [mailto:[EMAIL PROTECTED] Sent: Saturday, April 05, 2008 3:23 AM To: MyFaces Development Subject: The pdfExport component released ;) Hi guys, Iam pleased to tell you that the (PDFExport) component is finished. It works like the (excelExport) component. for example) s:pdfExport for=your table id h:commandButton action= value=Export as PDF/ /s:pdfExport Here is the patch url : https://issues.apache.org/jira/browse/TOMAHAWK-1229 Thanks all :). -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: The pdfExport component released ;)
Hi Alexander, I will do these changes as soon as I complete the excel and pdf export integration. Your suggestions are really nice! Thank you! On Mon, Apr 7, 2008 at 9:24 AM, Jesse Alexander (KSFH 323) [EMAIL PROTECTED] wrote: Hi From the sample code it seems that your component will just put the content of one table into the PDF. For the PDF-export it would make sense to also allow - multiple tables - forms - even complete views to be exportable. Would this require a big refactoring to be possible? regards Alexander -- *From:* Hazem Saleh [mailto:[EMAIL PROTECTED] *Sent:* Saturday, April 05, 2008 3:23 AM *To:* MyFaces Development *Subject:* The pdfExport component released ;) Hi guys, Iam pleased to tell you that the (PDFExport) component is finished. It works like the (excelExport) component. for example) s:pdfExport for=your table id h:commandButton action= value=Export as PDF/ /s:pdfExport Here is the patch url : https://issues.apache.org/jira/browse/TOMAHAWK-1229 Thanks all :). -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
[TRINIDAD] Scrolling Table - again...
Guys, For a while now I've been coming back to the table scrolling issue (TRINIDAD-656) we have in Trinidad. RIght now, it doesn't because the headers are rendered in the tbody, but also I believe it's overly difficult because of the complexity in how tr:table is rendered. Anyway, I created a patch for correcting the column headers and moving them into thead, which works fine. However, there's little point committing it, unless I can solve part 2. To get tables with scrolling tbody and fixed thead, the current table-in-table method of rendering makes this nearly impossible - at least for my small brain. It seems that most all css solutions for this are based on a simple table-in-div layout. So I guess I'm asking the following: 1.) Has anyone been able to do table scrolling (with fixed headers) using the current component? 2.) Why the current tr:table outputs so many table-in-table(-in-table) output, and why it doesn't juts do table-in-div I'm trying to determine if there's support for an overhaul of this component. Thanks, D. -- Chordiant Software Inc. www.chordiant.com
Re: [ANNOUNCE] AspectEL code donation
Incubation is definitely not necessary. The bits of code that you can download at http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip where built from scratch. The Aspect stuff that Gerald mentioned is not this library. He used a slightly different proprietary implementation. But the idea and concept where the same. AspectEL could be seen as a donation by a single MyFaces committer (= me). Don't think that we need an IP clearance in that case. So, should we start a voting then? --Manfred On Fri, Mar 28, 2008 at 3:56 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Manfred, sounds good. I strongly doubt, that an incubation of the library is required ;-) Not sure if we even need the much smaller process of the software grant / ip clearance. (Like we did with the portal bridge). I saw your presentation and like the main idea behind it, so I'll give you my +1 for a myfaces aspect el subproject. -Matthias On Fri, Mar 28, 2008 at 2:44 PM, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, As some of you already know (at least those who attended the JSFDays08 conference) I wrote a small goody project called AspectEL that I would like to donate to the MyFaces community. To give you an idea what it is about, here is the abstract of my presentation called Lightweight AOP with JSF: Dealing with entities and domain objects in your JSF views and backing beans is sometimes unnecessarily complicated. Aspect oriented programming would be a much more elegant way to add GUI specific logic directly to your entity classes rather than writing backing bean methods for all these GUI tasks. Real highly sophisticated AOP solutions might be overkill here and could make things even more complicated. This sessions shows you a surprisingly easy way of adding certain GUI aspects to your objects while dealing with them from within the presentation layer. Or in the words of a canvasser: AspectEL gives OOP back to your JSF managed beans :-) You could also have a look at the slides [1] for more details about the theory. If you are interested, please have a look at the source code and the example application at [2]. Just drop the example war into your Tomcat 5.x and manage your favorite beer brands. ;-) Please give me feedback. If there is enough interest I will start a discussion/vote thread about adding AspectEL as a new MyFaces sub project. Regards, Manfred [1] http://conference.irian.at/slidesvideo/pdfs/13_Th_14_Lightweight_AOP_with_JSF.pdf [2] http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOBAGO-644) sheet whithout paging ingnores silently rows 100
sheet whithout paging ingnores silently rows 100 -- Key: TOBAGO-644 URL: https://issues.apache.org/jira/browse/TOBAGO-644 Project: MyFaces Tobago Issue Type: Improvement Reporter: Volker Weber A tobago sheet without setup for paging is silently ignoring any row with index rows attibute which is 100 as default. This could be solved by: 1. setting default to unlimited or 2. auto config paging if to many rows. and enable configuring auto positions eg autoLeft,autoCenter, autoRight for showpagingType attibutes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-644) sheet whithout paging ingnores silently rows 100
[ https://issues.apache.org/jira/browse/TOBAGO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586421#action_12586421 ] Volker Weber commented on TOBAGO-644: - I prefer the 2. solution sheet whithout paging ingnores silently rows 100 -- Key: TOBAGO-644 URL: https://issues.apache.org/jira/browse/TOBAGO-644 Project: MyFaces Tobago Issue Type: Improvement Reporter: Volker Weber A tobago sheet without setup for paging is silently ignoring any row with index rows attibute which is 100 as default. This could be solved by: 1. setting default to unlimited or 2. auto config paging if to many rows. and enable configuring auto positions eg autoLeft,autoCenter, autoRight for showpagingType attibutes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: tobago island logo :)
Hi Adonis, thank you for your effort. The logo looks nice, but in my opinion it is too far away from the tobago shape. Is it possible, to make it more like the shape. I've tried to make a sample, but very raw. Regards Udo inline: tobago-logo.jpg
[Trinidad] select*Shuttle JavaScript issues (with Orchestra)
Hi, when using Trinidad's shuttle within an Orchestra application, the (re)move buttons are not usable. Why ? Because Trinidad creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Should we just stop to encode that client side action url ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] select*Shuttle JavaScript issues (with Orchestra)
Matthias, the bridge does url rewriting as well, and we ignore anything
that has a javascript: prefix. Basically, queryStrings only make
sense on URL's that are http and https (or stuff that resolves to
them). I think that orchestra's encodeActionURL needs to be smart
enough to handle this case?
Why? From a logistical standpoint, in the portal things have to be
encoded. Let say we have a tr:goLink that someone assigns to be
javascript:alert('hi);. There should be no reason this wouldn't work,
yet the go link always encodes it's URL. Should everything that
encode's it's URL have to handle all the perepherial cases or should the
implementation of the encodeActionURL be smart enough to take this into
account? I think the latter.
Therefore, I would say that orchestra should only append the
conversationContext if the protocol is http or https. Or do the
opposite (like the bridge does) and look for protocols to exclude like
ftp: and javascript:.
Scott
Matthias Wessendorf wrote:
Hi,
when using Trinidad's shuttle within an Orchestra application, the
(re)move buttons are not usable.
Why ?
Because Trinidad creates the javascript calls like
String url = javascript:TrShuttleProxy._moveItems(...;
and than, we internally encode the url.
Like facesContext.getExternalContext().encodeActionURL(url);
so... with Orchestra, you now get something like:
javascript:TrShuttleProxy._movetems();?conversationContext=3
which causes a JS syntax error.
Should we just stop to encode that client side action url ?
-M
Re: [Trinidad] select*Shuttle JavaScript issues (with Orchestra)
On Mon, Apr 7, 2008 at 6:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Matthias, the bridge does url rewriting as well, and we ignore anything that
has a javascript: prefix. Basically, queryStrings only make sense on
URL's that are http and https (or stuff that resolves to them). I think
that orchestra's encodeActionURL needs to be smart enough to handle this
case?
yeah, that is an option as well.
We really (IMO) don't need conversationContext for some client side things...
Why? From a logistical standpoint, in the portal things have to be
encoded. Let say we have a tr:goLink that someone assigns to be
javascript:alert('hi);. There should be no reason this wouldn't work, yet
the go link always encodes it's URL. Should everything that encode's it's
URL have to handle all the perepherial cases or should the implementation of
the encodeActionURL be smart enough to take this into account? I think the
latter.
Therefore, I would say that orchestra should only append the
conversationContext if the protocol is http or https. Or do the opposite
(like the bridge does) and look for protocols to exclude like ftp: and
javascript:.
+1
I will file an issue for that
-M
Scott
Matthias Wessendorf wrote:
Hi,
when using Trinidad's shuttle within an Orchestra application, the
(re)move buttons are not usable.
Why ?
Because Trinidad creates the javascript calls like
String url = javascript:TrShuttleProxy._moveItems(...;
and than, we internally encode the url.
Like facesContext.getExternalContext().encodeActionURL(url);
so... with Orchestra, you now get something like:
javascript:TrShuttleProxy._movetems();?conversationContext=3
which causes a JS syntax error.
Should we just stop to encode that client side action url ?
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
[jira] Created: (ORCHESTRA-21) URLs are always encoded
URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] select*Shuttle JavaScript issues (with Orchestra)
On Mon, Apr 7, 2008 at 6:43 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 6:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Matthias, the bridge does url rewriting as well, and we ignore anything
that
has a javascript: prefix. Basically, queryStrings only make sense on
URL's that are http and https (or stuff that resolves to them). I think
that orchestra's encodeActionURL needs to be smart enough to handle this
case?
yeah, that is an option as well.
We really (IMO) don't need conversationContext for some client side things...
Why? From a logistical standpoint, in the portal things have to be
encoded. Let say we have a tr:goLink that someone assigns to be
javascript:alert('hi);. There should be no reason this wouldn't work,
yet
the go link always encodes it's URL. Should everything that encode's it's
URL have to handle all the perepherial cases or should the implementation
of
the encodeActionURL be smart enough to take this into account? I think the
latter.
Therefore, I would say that orchestra should only append the
conversationContext if the protocol is http or https. Or do the opposite
(like the bridge does) and look for protocols to exclude like ftp: and
javascript:.
+1
I will file an issue for that
http://issues.apache.org/jira/browse/ORCHESTRA-21
-M
Scott
Matthias Wessendorf wrote:
Hi,
when using Trinidad's shuttle within an Orchestra application, the
(re)move buttons are not usable.
Why ?
Because Trinidad creates the javascript calls like
String url = javascript:TrShuttleProxy._moveItems(...;
and than, we internally encode the url.
Like facesContext.getExternalContext().encodeActionURL(url);
so... with Orchestra, you now get something like:
javascript:TrShuttleProxy._movetems();?conversationContext=3
which causes a JS syntax error.
Should we just stop to encode that client side action url ?
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [proposal] jsf validation with annotations
Hi All... There is already an ongoing activity to implement JSR#303 - http://www.jcp.org/en/jsr/detail?id=303 - and we started it as an Apache Commons Sandbox project. Following links for discussion threads and the svn repo of the new project: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102655 http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102683 http://svn.apache.org/repos/asf/commons/sandbox/validator2/ IMHO this will be a good base for more specific validation requirements, like JSF or EJB specific validations. On Sat, Apr 5, 2008 at 2:02 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello cagatay, i see your point. however, i don't agree. to keep it short: i don't like the idea to restrict sev-en to orchestra. don't get me wrong - orchestra is really great! however, it isn't alone out there. (e.g. spring web flow and much more) if sev-en is a goody or not is in the eye of the beholder. i would say e.g.: the possible jpa support is a goody of sev-en. (the core of sev-en doesn't depend on jpa or something else. the core depends only on the jsf api and at the moment on commons-logging ;)) regards, gerhard 2008/4/4, Cagatay Civici [EMAIL PROTECTED]: Hi, I think Orchestra is kinda out of it's original scope, Mario and Simon couldn't resist and add many cool useful features like viewController, dynaForm and more that are not related to conversations and persistence. Orchestra is becoming our alternative to seam, sev-en is a goodie right? So rather than a seperate project, I've no problem if it gets merged in Orchestra, just my 2 cents, it's up to further discussion. Cagatay On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann [EMAIL PROTECTED] wrote: *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 2:47 PM *To:* MyFaces Development; [EMAIL PROTECTED] *Subject:* Re: [proposal] jsf validation with annotations hello kito, you can put every extension into a commons module. I see what you're saying. I suppose the main issue is the size of the module, and the number of perceived users. To be honest, I think Tomahawk is a better place for it, since Tomahawk contains a lot of stuff that belongs in the JSF core, like some basic validators. orchestra is about conversations and persistence and sev-en is about validation (simple and cross-component validation) at the moment i'm not aware of the difference. it might be ok to put specific sev-en annotation modules into the commons module (as i said - they are independent of the sev-en core). regards, gerhard 2008/4/4, Kito D. Mann [EMAIL PROTECTED]: Gerhard, Actually, it's different. Commons is a collection of useful utilities and features. Think of it in terms of the Apache Commons. Orchestra is about conversations and persistence contexts. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 12:56 PM *To:* MyFaces Development *Subject:* Re: [proposal] jsf validation with annotations hello leonardo, concerning myfaces-commons-sev-en: i don't agree. it's similar if you suggest to merge myfaces-orchestra with myfaces-commons. - in my opinion that's not a good idea. sev-en should stay independent! + commons-sev-en sounds strage. :) (the pronunciation isn't [sev] ... [en] - it's like the 7 in english) regards, gerhard 2008/4/4, Leonardo Uribe [EMAIL PROTECTED]: I have tried the demo on my workstation, and in my opinion is a very cool idea and this should be on myfaces :) The idea of include with myfaces-commons sounds better that put this on orchestra (someone could want to use this only). Maybe myfaces-commons-sev-en. regards Leonardo Uribe On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello andrew, sev-en is completely independent of orchestra or the idea behind it. regards, gerhard 2008/4/4, Andrew Robinson [EMAIL PROTECTED]: Since this is currently supported in Seam and Orchestra is a Seam spin-off/clone, perhaps this should be incorporated into Orchestra instead of yet another project. On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: sev-en is a new jsf-extension. sev-en allows jsf validation with annotations!
[jira] Resolved: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-21. --- Resolution: Fixed Fix Version/s: 2.0 Assignee: Mario Ivankovits We will encode now only if the url starts with http* URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586514#action_12586514
]
Jean-François Poirier commented on MYFACES-1692:
I think there is no need for the option to be present if the implementation is
broken. User doc is not available on the issue (except here and some deep
mailing list posts).
I suggest bringing it back as a bug (because it IS broken) - but the solution
would be to just remove the option until the implementation works again. User
confusion is not good.
Simon's solution is good but should come with a warning that the code is using
that mode. converting text to buttons has side effects like broken copypaste
on IE 6. (removes all space before the button for some reason and adding nbsp;
doesn't correct the problem).
Updating user doc with a tip on how to do it would be equally good in my
perspective since it's so simple.
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [proposal] jsf validation with annotations
hello, (the sev-en core doesn't provide specific annotations. maybe there will be an annotation module to support jsr 303 annotations, which might act as adapter for the project you mentioned.) or are you suggesting to publish sev-en as a sub-project of the commons project? regards, gerhard 2008/4/7, Hazem Saleh [EMAIL PROTECTED]: Hi All... There is already an ongoing activity to implement JSR#303 - http://www.jcp.org/en/jsr/detail?id=303 - and we started it as an Apache Commons Sandbox project. Following links for discussion threads and the svn repo of the new project: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102655 http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102683 http://svn.apache.org/repos/asf/commons/sandbox/validator2/ IMHO this will be a good base for more specific validation requirements, like JSF or EJB specific validations. On Sat, Apr 5, 2008 at 2:02 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello cagatay, i see your point. however, i don't agree. to keep it short: i don't like the idea to restrict sev-en to orchestra. don't get me wrong - orchestra is really great! however, it isn't alone out there. (e.g. spring web flow and much more) if sev-en is a goody or not is in the eye of the beholder. i would say e.g.: the possible jpa support is a goody of sev-en. (the core of sev-en doesn't depend on jpa or something else. the core depends only on the jsf api and at the moment on commons-logging ;)) regards, gerhard 2008/4/4, Cagatay Civici [EMAIL PROTECTED]: Hi, I think Orchestra is kinda out of it's original scope, Mario and Simon couldn't resist and add many cool useful features like viewController, dynaForm and more that are not related to conversations and persistence. Orchestra is becoming our alternative to seam, sev-en is a goodie right? So rather than a seperate project, I've no problem if it gets merged in Orchestra, just my 2 cents, it's up to further discussion. Cagatay On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann [EMAIL PROTECTED] wrote: *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 2:47 PM *To:* MyFaces Development; [EMAIL PROTECTED] *Subject:* Re: [proposal] jsf validation with annotations hello kito, you can put every extension into a commons module. I see what you're saying. I suppose the main issue is the size of the module, and the number of perceived users. To be honest, I think Tomahawk is a better place for it, since Tomahawk contains a lot of stuff that belongs in the JSF core, like some basic validators. orchestra is about conversations and persistence and sev-en is about validation (simple and cross-component validation) at the moment i'm not aware of the difference. it might be ok to put specific sev-en annotation modules into the commons module (as i said - they are independent of the sev-en core). regards, gerhard 2008/4/4, Kito D. Mann [EMAIL PROTECTED]: Gerhard, Actually, it's different. Commons is a collection of useful utilities and features. Think of it in terms of the Apache Commons. Orchestra is about conversations and persistence contexts. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 12:56 PM *To:* MyFaces Development *Subject:* Re: [proposal] jsf validation with annotations hello leonardo, concerning myfaces-commons-sev-en: i don't agree. it's similar if you suggest to merge myfaces-orchestra with myfaces-commons. - in my opinion that's not a good idea. sev-en should stay independent! + commons-sev-en sounds strage. :) (the pronunciation isn't [sev] ... [en] - it's like the 7 in english) regards, gerhard 2008/4/4, Leonardo Uribe [EMAIL PROTECTED]: I have tried the demo on my workstation, and in my opinion is a very cool idea and this should be on myfaces :) The idea of include with myfaces-commons sounds better that put this on orchestra (someone could want to use this only). Maybe myfaces-commons-sev-en. regards Leonardo Uribe On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello andrew, sev-en is completely independent of orchestra or the idea behind it. regards, gerhard
Re: [proposal] jsf validation with annotations
Hello, Iam just suggesting a standard way of validation that we are going to implement in the next days which can be useful later for JSF or EJB projects. This project is currently a subproject of the apache commons project. IMHO if sev-en can support JSR-303 annotations, this will be great! Thank you. On Mon, Apr 7, 2008 at 10:24 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, (the sev-en core doesn't provide specific annotations. maybe there will be an annotation module to support jsr 303 annotations, which might act as adapter for the project you mentioned.) or are you suggesting to publish sev-en as a sub-project of the commons project? regards, gerhard 2008/4/7, Hazem Saleh [EMAIL PROTECTED]: Hi All... There is already an ongoing activity to implement JSR#303 - http://www.jcp.org/en/jsr/detail?id=303 - and we started it as an Apache Commons Sandbox project. Following links for discussion threads and the svn repo of the new project: http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102655 http://thread.gmane.org/gmane.comp.jakarta.commons.devel/102683 http://svn.apache.org/repos/asf/commons/sandbox/validator2/ IMHO this will be a good base for more specific validation requirements, like JSF or EJB specific validations. On Sat, Apr 5, 2008 at 2:02 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello cagatay, i see your point. however, i don't agree. to keep it short: i don't like the idea to restrict sev-en to orchestra. don't get me wrong - orchestra is really great! however, it isn't alone out there. (e.g. spring web flow and much more) if sev-en is a goody or not is in the eye of the beholder. i would say e.g.: the possible jpa support is a goody of sev-en. (the core of sev-en doesn't depend on jpa or something else. the core depends only on the jsf api and at the moment on commons-logging ;)) regards, gerhard 2008/4/4, Cagatay Civici [EMAIL PROTECTED]: Hi, I think Orchestra is kinda out of it's original scope, Mario and Simon couldn't resist and add many cool useful features like viewController, dynaForm and more that are not related to conversations and persistence. Orchestra is becoming our alternative to seam, sev-en is a goodie right? So rather than a seperate project, I've no problem if it gets merged in Orchestra, just my 2 cents, it's up to further discussion. Cagatay On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann [EMAIL PROTECTED] wrote: *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 2:47 PM *To:* MyFaces Development; [EMAIL PROTECTED] *Subject:* Re: [proposal] jsf validation with annotations hello kito, you can put every extension into a commons module. I see what you're saying. I suppose the main issue is the size of the module, and the number of perceived users. To be honest, I think Tomahawk is a better place for it, since Tomahawk contains a lot of stuff that belongs in the JSF core, like some basic validators. orchestra is about conversations and persistence and sev-en is about validation (simple and cross-component validation) at the moment i'm not aware of the difference. it might be ok to put specific sev-en annotation modules into the commons module (as i said - they are independent of the sev-en core). regards, gerhard 2008/4/4, Kito D. Mann [EMAIL PROTECTED]: Gerhard, Actually, it's different. Commons is a collection of useful utilities and features. Think of it in terms of the Apache Commons. Orchestra is about conversations and persistence contexts. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED] *Sent:* Friday, April 04, 2008 12:56 PM *To:* MyFaces Development *Subject:* Re: [proposal] jsf validation with annotations hello leonardo, concerning myfaces-commons-sev-en: i don't agree. it's similar if you suggest to merge myfaces-orchestra with myfaces-commons. - in my opinion that's not a good idea. sev-en should stay independent! + commons-sev-en sounds strage. :) (the pronunciation isn't [sev] ... [en] - it's like the 7 in english) regards, gerhard 2008/4/4, Leonardo Uribe [EMAIL PROTECTED]: I have
[jira] Updated: (TRINIDAD-996) improvement of defaultCommand
[ https://issues.apache.org/jira/browse/TRINIDAD-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David updated TRINIDAD-996: --- Status: Patch Available (was: Open) improvement of defaultCommand - Key: TRINIDAD-996 URL: https://issues.apache.org/jira/browse/TRINIDAD-996 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Gerhard Petracek see: http://www.nabble.com/-Trinidad--subform-defaultCommand-p15815227.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-996) improvement of defaultCommand
[ https://issues.apache.org/jira/browse/TRINIDAD-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586557#action_12586557 ] David commented on TRINIDAD-996: Is it possible to see your java script? I see your comments about pathes and examples but how do I download them? improvement of defaultCommand - Key: TRINIDAD-996 URL: https://issues.apache.org/jira/browse/TRINIDAD-996 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Gerhard Petracek see: http://www.nabble.com/-Trinidad--subform-defaultCommand-p15815227.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-996) improvement of defaultCommand
[ https://issues.apache.org/jira/browse/TRINIDAD-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586567#action_12586567 ] Gerhard Petracek commented on TRINIDAD-996: --- hello david, you will find the script + a sample file (which contains several possible usage-scenarios) at my os890 project. currently at: http://code.google.com/p/os890/source/browse/trunk/javascript/generic/default_command/smartDefaultCommand.js and http://code.google.com/p/os890/source/browse/trunk/javascript/generic/default_command/smartDefaultCommand_examples_with_trinidad.txt regards, gerhard improvement of defaultCommand - Key: TRINIDAD-996 URL: https://issues.apache.org/jira/browse/TRINIDAD-996 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Gerhard Petracek see: http://www.nabble.com/-Trinidad--subform-defaultCommand-p15815227.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1851) the hidden field form:_link_hidden_ not works anymore (changed by form:_idcl on MYFACES-1539). This should be removed
the hidden field form:_link_hidden_ not works anymore (changed by form:_idcl on MYFACES-1539). This should be removed - Key: MYFACES-1851 URL: https://issues.apache.org/jira/browse/MYFACES-1851 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The hidden field _link_hidden_ was replaced with _idcl, but actually on 1.2 this field does nothing. The better option is remove this field from rendering. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-996) improvement of defaultCommand
[ https://issues.apache.org/jira/browse/TRINIDAD-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated TRINIDAD-996: -- Status: Open (was: Patch Available) improvement of defaultCommand - Key: TRINIDAD-996 URL: https://issues.apache.org/jira/browse/TRINIDAD-996 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Gerhard Petracek see: http://www.nabble.com/-Trinidad--subform-defaultCommand-p15815227.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-951) Printable output mode produces javascript errors
[
https://issues.apache.org/jira/browse/TRINIDAD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586596#action_12586596
]
Cristi Toth commented on TRINIDAD-951:
--
btw, thanks to Harald Kuhn for most of the bits of code
Printable output mode produces javascript errors
Key: TRINIDAD-951
URL: https://issues.apache.org/jira/browse/TRINIDAD-951
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.2-core
Environment: Jdk 1.6, Jetty 6.1.5, Facelets 1.1.13, MyFaces JSF
1.2.2, Trinidad 1.2.2
Reporter: Joe Rossi
Assignee: Cristi Toth
Priority: Minor
Fix For: 1.0.8-core, 1.2.8-core
A page rendered with trinidad-config.xml output-mode set to printable
contains javascript errors. The example below (widgetList.xhtml) contains a
couple of command buttons and a table. When the command button 'Printable
Page' is clicked it sets the requestScope.outputMode to 'printable' and this
is used to drive the output-mode setting in trinidad-config.xml. Looking at
the generated html, it looks like there is no reference to the usual
javascript file required by Trinidad (DebugCommon1_2_2.js or Common1_2_2.js).
trinidad-config.xml:
===
?xml version=1.0?
trinidad-config xmlns=http://myfaces.apache.org/trinidad/config;
!--
Enable this setting to cause Trinidad to generate debug output.
debug-outputtrue/debug-output
--
skin-familytn/skin-family
output-mode#{requestScope.outputMode}/output-mode
/trinidad-config
Test file: widgetList.xhtml:
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
tr:document id=testForm title=test form
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:tr=http://myfaces.apache.org/trinidad;
tr:panelBorderLayout
tr:form id=widgetListForm
tr:panelGroupLayout layout=vertical
tr:commandButton text=Create New Widget
action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=createWidgetCommand
tr:setActionListener from=#{widgetListBean.newWidgetBean}
to=#{pageFlowScope.widgetBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.widgetBean.operation} /
/tr:commandButton
tr:commandButton text=Refresh Page id=refreshCommand
/tr:commandButton
tr:commandButton text=Printable Page id=printablePageCommand
tr:setActionListener from=#{'printable'}
to=#{requestScope.outputMode} /
/tr:commandButton
tr:table id=widgetTable var=widgetBean
value=#{widgetListBean.widgetList} rowBandingInterval=1
partialTriggers=refreshCommand createWidgetCommand
widgetTable:editWidgetCommand widgetTable:deleteWidgetCommand
tr:column
f:facet name=header
tr:outputText value=Widget Name /
/f:facet
tr:outputText value=#{widgetBean.name} /
/tr:column
tr:column
f:facet name=header
tr:outputText value=Actions /
/f:facet
tr:panelGroupLayout layout=horizontal
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=editWidgetCommand
shortDesc=Edit the widget.
tr:image source=/skins/tn/images/ico_edit.gif /
tr:setActionListener from=#{'edit'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=deleteWidgetCommand
shortDesc=Delete the widget.
returnListener=#{widgetListBean.processReturn}
tr:image source=/skins/tn/images/ico_delete.gif /
tr:setActionListener from=#{'delete'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
/tr:panelGroupLayout
/tr:column
/tr:table
/tr:panelGroupLayout
/tr:form
/tr:panelBorderLayout
/tr:document
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
[jira] Resolved: (TRINIDAD-951) Printable output mode produces javascript errors
[
https://issues.apache.org/jira/browse/TRINIDAD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cristi Toth resolved TRINIDAD-951.
--
Resolution: Fixed
Fix Version/s: 1.2.8-core
1.0.8-core
Assignee: Cristi Toth
I fixed some renderers using statement similar to this:
if (supportsScripting(rc))
{
...
old code rendering scripts
..
}
this is because in output mode printable scripting is disabled
so no need for rendering scripts or on event handlers
they usually generated js erros because the js dependencies were not found
Printable output mode produces javascript errors
Key: TRINIDAD-951
URL: https://issues.apache.org/jira/browse/TRINIDAD-951
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.2-core
Environment: Jdk 1.6, Jetty 6.1.5, Facelets 1.1.13, MyFaces JSF
1.2.2, Trinidad 1.2.2
Reporter: Joe Rossi
Assignee: Cristi Toth
Priority: Minor
Fix For: 1.0.8-core, 1.2.8-core
A page rendered with trinidad-config.xml output-mode set to printable
contains javascript errors. The example below (widgetList.xhtml) contains a
couple of command buttons and a table. When the command button 'Printable
Page' is clicked it sets the requestScope.outputMode to 'printable' and this
is used to drive the output-mode setting in trinidad-config.xml. Looking at
the generated html, it looks like there is no reference to the usual
javascript file required by Trinidad (DebugCommon1_2_2.js or Common1_2_2.js).
trinidad-config.xml:
===
?xml version=1.0?
trinidad-config xmlns=http://myfaces.apache.org/trinidad/config;
!--
Enable this setting to cause Trinidad to generate debug output.
debug-outputtrue/debug-output
--
skin-familytn/skin-family
output-mode#{requestScope.outputMode}/output-mode
/trinidad-config
Test file: widgetList.xhtml:
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
tr:document id=testForm title=test form
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:tr=http://myfaces.apache.org/trinidad;
tr:panelBorderLayout
tr:form id=widgetListForm
tr:panelGroupLayout layout=vertical
tr:commandButton text=Create New Widget
action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=createWidgetCommand
tr:setActionListener from=#{widgetListBean.newWidgetBean}
to=#{pageFlowScope.widgetBean} /
tr:setActionListener from=#{'create'}
to=#{pageFlowScope.widgetBean.operation} /
/tr:commandButton
tr:commandButton text=Refresh Page id=refreshCommand
/tr:commandButton
tr:commandButton text=Printable Page id=printablePageCommand
tr:setActionListener from=#{'printable'}
to=#{requestScope.outputMode} /
/tr:commandButton
tr:table id=widgetTable var=widgetBean
value=#{widgetListBean.widgetList} rowBandingInterval=1
partialTriggers=refreshCommand createWidgetCommand
widgetTable:editWidgetCommand widgetTable:deleteWidgetCommand
tr:column
f:facet name=header
tr:outputText value=Widget Name /
/f:facet
tr:outputText value=#{widgetBean.name} /
/tr:column
tr:column
f:facet name=header
tr:outputText value=Actions /
/f:facet
tr:panelGroupLayout layout=horizontal
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=editWidgetCommand
shortDesc=Edit the widget.
tr:image source=/skins/tn/images/ico_edit.gif /
tr:setActionListener from=#{'edit'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
to=#{pageFlowScope.widgetBean} /
/tr:commandLink
tr:commandLink action=dialog:widgetDialog
useWindow=true partialSubmit=true
windowHeight=300 windowWidth=400
id=deleteWidgetCommand
shortDesc=Delete the widget.
returnListener=#{widgetListBean.processReturn}
tr:image source=/skins/tn/images/ico_delete.gif /
tr:setActionListener from=#{'delete'}
to=#{widgetBean.operation} /
tr:setActionListener from=#{widgetBean}
[jira] Commented: (TOMAHAWK-616) Datatable AutoSort and Facelets Bug
[ https://issues.apache.org/jira/browse/TOMAHAWK-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586601#action_12586601 ] Daniel Vidal Salvi Marson commented on TOMAHAWK-616: I've the same problem in my aplication. The order is rendered in String, but my attribute is Long type Datatable AutoSort and Facelets Bug --- Key: TOMAHAWK-616 URL: https://issues.apache.org/jira/browse/TOMAHAWK-616 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.3 Environment: Windows XP Professional JBoss 4.03 SP1 Tomahawk 1.14 Snapshot and MyFaces 1.14 Snapshot Reporter: Tom Innes Attachments: DatatableTestFacelets.zip I am having problems with the auto sort feature after converting my application to facelets. The sorting only sorts one way ( ascending ) and the arrows are never displayed. I have tried 1.13 and 1.14 versions and there is no difference in the behaviour. I have converted the car example to highlight the problem it is attached. It is an eclipse project and the war is called DataTableTestFacelets. Just press the Find Button and then click on the links to sort the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-921) Add/Fix Support for Windows Mobile 6/5 and BlackBerry
[ https://issues.apache.org/jira/browse/TRINIDAD-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford updated TRINIDAD-921: Resolution: Fixed Fix Version/s: 1.2.8-core 1.0.8-core Status: Resolved (was: Patch Available) Add/Fix Support for Windows Mobile 6/5 and BlackBerry - Key: TRINIDAD-921 URL: https://issues.apache.org/jira/browse/TRINIDAD-921 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.5-core Environment: PDA, Mobile, Windows Mobile 5, Windows Mobile 6 and BlackBerry Reporter: Tadashi Enomori Assignee: Gabrielle Crawford Priority: Minor Fix For: 1.0.8-core, 1.2.8-core Attachments: TRINIDAD-921.patch, TRINIDAD-921_Revised_1_1.0.x.patch, TRINIDAD-921_Revised_1_1.2.x.patch, TRINIDAD-921_Revised_2_1.0.x.patch, TRINIDAD-921_Revised_2_1.2.x.patch, TRINIDAD-921_Revised_3_1.0.x.patch, TRINIDAD-921_Revised_3_1.2.x.patch, TRINIDAD-921_Revised_4_1.0.x.patch, TRINIDAD-921_Revised_4_1.2.x.patch Add PPR support Windows Mobile 6 that leverages Windows Mobile 6 version of XMLHttpRequest and DOM support. Remove non-functional code that intends to implement PPR for Windows Mobile 5. Fix various crush in JavaScript due to browser differences on Windows Mobile 5, Windows Mobile 6 and BlackBerry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1852) autoscroll feature does not work with tomahawk and myfaces 1.2
autoscroll feature does not work with tomahawk and myfaces 1.2
--
Key: MYFACES-1852
URL: https://issues.apache.org/jira/browse/MYFACES-1852
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
The problem is shown here:
the method renderAutoScrollFunction is not called anymore, so the feature is
broken.
There exists a issue MYFACES-1662 Move autoscroll feature from shared
HtmlRendererUtils to Tomahawk, but for now we should restore this feature first
and then move this stuff.
The javascript added on the button and link looks like this:
if(typeof window.getScrolling!='undefined'){
oamSetHiddenInput('form','autoScroll',getScrolling());
}
oamSetHiddenInput create a input hidden through javascript, suggesting a more
compatible solution than use input hidden fields rendered at encodeEnd of a
form. Other task should be change input hidden fields feature using
oamSetHiddenInput instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
