RE: Orchestra on code.google.com
I do what I can, be pointing it out, whenever a question pops up on something we have there... but you are right, more publicity makes sense... regards Alexander -Original Message- From: Kito D. Mann [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 11:51 PM To: 'MyFaces Development' Subject: RE: Orchestra on code.google.com If you guys decide to use JSF comp, I suggest pushing them for a little better PR. No one really knows all of the goodies they have... ~~~ 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 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: Andrew Robinson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:50 PM To: MyFaces Development Subject: Re: Orchestra on code.google.com Use the jsf-comp space for myfaces-orchestra non-asf license compatible stuff. (Given the project owners accept it ;-) ) No problem with me to use Jsf-Comp
RE: Orchestra on code.google.com
Of course we accept it... We put jsf-comp to live to have a haven for non-adf-compatible stuff. Better host it on such a side-project, than nowhere... module name is up to you. (Personally i think it is a little bit long, but the module-creator is in the driver seat). Just give me an info, when you decide upon it and tell me the module-name, than I will setup the file-delivery-package (seems that's about the only thing only admins can do). regards Alexander -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 10:57 AM To: MyFaces Development Subject: Re: Orchestra on code.google.com Cagatay Civici wrote: Mario, What about stability of sourceforge lately? I used it in the past, but was disappointed about speed and reachability. I had no problems with sourceforge for a long time when working on jsf-comp. Ok, so lets sum up ... Use the jsf-comp space for myfaces-orchestra non-asf license compatible stuff. (Given the project owners accept it ;-) ) Use the module name myfaces-orchestra-goodies. What do you think? Ciao, Mario
RE: Orchestra on code.google.com
how about using jsf-comp.sf.net? got initiated for that reason... and a few of the components are used... regards Alexander -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 3:29 PM To: MyFaces Development Subject: Orchestra on code.google.com Hi! code.google.com is fine for that. I'd like to start a project at code.google.com to host any code not allowed (or not easily allowed) by the policy of ASF. e.g. when depending on (L)GPL code. I reserved a name already [1]. Any objections about it? Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-nonasf
RE: Portlets a href=: resource or action URL?
Adam mentions iframe/frame-src attributes... I guess those would qualify as resource-url's ? regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 6:25 AM To: MyFaces Development Subject: Re: Portlets a href=: resource or action URL? Definitely encodeActionUrl, yes, from what I read in the portlet spec. Obviously the original link implementors thought the distinction was about form post versus get - but the distinction is about query links/form submissions versus inclusion of resources in the page. regards, Martin On 6/14/07, Adam Winer [EMAIL PROTECTED] wrote: Simple (I imagine) question: For a link's href, should we be calling encodeResourceURL() or encodeActionURL()? I've always assumed these are action URLs. I see other code out there (MyFaces outputLink, for example) that considers these resource URLs. (Whatever answer we arrive at should apply equally to iframe and frame src attributes, I believe). -- Adam -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
sounds good... and the 4-number version mirrors somewhat the RI, they are at 1.2_04P02 so +1 (non-binding from me) A20.1. not solved. Well, MyFaces is not Tomcat... It is something confusing with Tomcat... one has to search the ewb to know which servlet-spec correlates to which tomcat... so MyFaces improves in this area! A20.5. not solved, but if there is a JSF fix we must join all our influence and convice Ed to call it JSF-1.3 ;-) I would say a bug-fix release of the spec is not important enough to be reflected into the version number of MyFaces. If necessary it will prompt a new impl-minor number to comply... And the discussion about the spec-version usually is held on ##jsf. And some MyFaces-fans are there present. Bruno and Wendy, every now and then show up... and I'm a regular A20.5. not solved, but if there is a JSF fix we must join all our influence and convice Ed to call it JSF-1.3 ;-) This only happens if there is a minor release of the spec do we have seen something in the past? No, but it has been discussed already once. ;) An argument for having bug-versions of the spec is the deployment in big corporations which are (usually) very change-unfriendly. So developers have more problems to slip in a new version complying to a new minor of the spec than being forced to apply the version because of identified bugs... But I would not expect official spec-releases other than the JSF-nextGeneration spec (JSF 2.0 or JSF6, I fear the latter still has its lobby). regards Alexander -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Geiler Sent: Friday, May 25, 2007 10:32 AM To: MyFaces Development Subject: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0) Hi all, I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I will try to summarize all of the arguments and collect the pros and cons once more. The goal is to find a compromise that is acceptable for all of us. I will try to be as impartial as possible. You will see I'm no pigheaded person. Not always at least... ;-) Requisites: R1. Users (esp. non-community members) must be able to find out the implemented spec version (JSR) easily. R2. We must be able to distinguish bugfix releases from feature releases (with changes or extended API). Arguments pro 1.2.x: A12.1. MyFaces 1.2.x is more intuitive and easier to explain to non-community members. A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds strange and will confuse people. A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces 2.0.x implementation which will confuse people even more. A12.4. The JSR-252 MyFaces API lib would get the name myfaces-api-2.0.0.jar (!). Mind: This is a new argument pro 1.2.x! ;-) A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that doesn't have giant technology changes in its core. A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a specific MyFaces core release, and should use whatever versions make the most sense. A12.7. Free evolution of myfaces-impl is possible, but would come at a cost of incompatibility with the RI. Arguments pro 2.x.y: A20.1. Tomcat does the same. They do not align there container versions to the spec and nobody complains. A20.2. Degree of freedom with minor (x) and fix (y) number. Feature releases with changed or extended API will have a higher minor number. Releases that only fix bugs will only count up the y number. A20.3. Aligning the version numbers of core and component libs within the MyFaces umbrella would be easier. A20.4. MyFaces API can stay with a version number of 1.2, though. A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ? A20.6. What do we do when there is a major refactoring of MyFaces, similar to Tomcat 5.0 and 5.5 Ok, here is my compromise proposal, which I hope everyone can live with: C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which means major-spec-version.minor-spec-version.minor-impl-version.fix-vers ion C2. We leave the 1.1.5 branch version numbering. Should there ever be the need for doing a fix in that branch (security, copyright issues) we will release a 1.1.6. C3. Non-core libs will no longer be aligned to Core. Which means that Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0 or 2.0.0 or any appropriate number whenever there are major feature additions or global refactorings. All Requistes accomplished? R1: yes R2: yes Arguments? A12.1. solved A12.2. solved A12.3. solved A12.4. solved A12.5. solved A12.6. solved A12.7. not constricted A20.1. not solved. Well, MyFaces is not Tomcat... A20.2. solved A20.3. not solved, but identified as no longer necessary/desired A20.4. solved A20.5. not solved, but if there is a JSF fix we must join all our influence and convice Ed to call it JSF-1.3 ;-) A20.6. solved, we could switch to 1.2.5.x Somebody mentioned that this
RE: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
I can see reasons for making it 2.0 (API-changes) but it is much more intuitive to us the same major/minor as the specification-release. +1 (non-binding) for JSF 1.2 == MyFaces 1.2 Alexander -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, May 18, 2007 6:29 AM To: MyFaces Development Subject: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?) So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred
RE: [POLL] Fusion Naming
Hi Mario will you provide the source for these apps? grats on a cool new way to vote... regards Alexander -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 1:57 PM To: MyFaces Development Subject: Re: [POLL] Fusion Naming Hi Manfred! Cool application! Thanks! Sad that there are so few votes yet... :-( Yeah, anyway, I'll close the vote today and will come up (as it looks like now) with the top three names. Ciao, Mario
RE: [VOTE] New Apache MyFaces Fusion Name
[+] Apache MyFaces Orchestra [ ] Apache MyFaces Aurora [ ] Apache MyFaces Connections regards Alexander
RE: [VOTE] New Apache MyFaces Fusion Name
you mean something like: programming JSF without glue?... you must be without a clue! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Thursday, March 08, 2007 10:48 PM To: MyFaces Development Subject: Re: [VOTE] New Apache MyFaces Fusion Name only because the name is so funny :-) kleber == glue ;) to native speakers glue must also sound funny :-)) On 3/8/07, Jeff Bischoff [EMAIL PROTECTED] wrote: matze, you're such a rebel. ;) Matthias Wessendorf wrote: [x] Apache MyFaces Kleber On 3/8/07, Jeff Bischoff [EMAIL PROTECTED] wrote: [x] Apache MyFaces Orchestra [ ] Apache MyFaces Aurora [ ] Apache MyFaces Connections -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[OT] ping Martin Marinscheck
Hi Martin please contact me... your gmail-account today did not accept direct email sorry for the OT... Alexander Jesse
RE: Commons Jsf Utils
Does it make sense to coordinate together with SUN... as you define the goal must not depend on a certain JSF implementation regards Alexander -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 10:50 AM To: MyFaces Development Subject: Commons Jsf Utils Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred
RE: Option for NavigationHandler to support viewIds as outcome
If you specify the navigation in the faces-config.xml, then you are already using a configuration parameter... I this case you would not have to define another web-context parameter... The idea sounds like the DefaultServlet from Tomcat... easy to become addited to ;) regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 9:52 AM To: MyFaces Development Subject: Re: Option for NavigationHandler to support viewIds as outcome I definitely think Ernst's idea is a good one - and I do think that a configuration-parameter for adding this would be optimal. The dummy-form stuff was not compatible with the RI, overwriting a navigation-handler in tomahawk, behaving differently if a configuration parameter is set; would of course be! regards, Martin On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: look at the nh_impl. you see it :) On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hmm, sounds interesting, what exactly would you have in mind, something like a Callback for additional security checks which receives the viewId and then can check wheather or not access is allowed and return a boolean or so? On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl for accessing navigation cases. It is important in security cases to *check* navigation cases ... so your impl could benefit from that ! On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: You're right, an alternate NavigationHandler shipped with MyFaces is probably the better choice let's go with that approach. thanks for your ideas On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: 2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes Sorry don't get your point here, if an action returns a misspelled outcome or a misspelled viewId you would not want to navigate in both cases right? I think he means the 404 error, ... However, I kinda like stuff like that, but not configurable! We had had enough fun with bogus features like dummyForm. We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if sb. really really want that, use that particular NH. just my $0.02 -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT
well accessability laws are not the only requirements... Some companies request that webapps must work with JS disabled for SECURITY reasons. JS is considered a big risk, on the same level as ActiveX. EG. checkout the links on http://ajaxtopics.com/security.html or this article http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/. asking the search engines for security risk javascript you hardly find a hit that claims otherwise... For JSF 2.0 I asked Ed to include a requirement to add gracefull degradation- specifications. Components should behave in a defined way, when some of their dependencies (like missing JS) are not available. I consider designing JS-free UI's a bigger challenge than so called Rich UI's. It is more difficult to come up with a user-friendly solutoin, but I have seen applications migrated from a complex Smalltalk-Fat-client UI to a JS-free webapp UI, and see that the users appreciated the simplification of the UI. It ended up more in a step by step UI, which was easier to understand. regards Alexander -Original Message- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 4:32 AM To: MyFaces Development Subject: Re: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT Jesse, Yes, commandLink is the only component in the JSF impl that emits Javascript. That's because the set of components in the JSF spec is minimal, and the set of features on those few components is minimal. It does not constitute proof that any component that uses Javascript is being silly. I also have yet to see much evidence that JS-free pages are truly necessary today (a common claim that accessibility laws require functioning without Javascript is false.) I'm fine with the goal of avoiding Javascript except when necessary, and fine with documenting which components require it and which don't. Anything more is, well, very 20th century. Regards, Adam Winer On 10/26/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: The newest JSF-RI release (1.2_03) does not emmit anymore JS according to Ed. Only exception is the command-link... and for that one I discussed a possible solution with Ryan, which will be tried sometime soon... regards Alexander and: JS-free pages are definitely necessary... -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 8:14 PM To: MyFaces Development Subject: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT Hold on with Tiles support - it works without problems even in the current MyFaces-version. Javascript stuff - yes, we need javascript. No way round it, except you use only command-buttons. regards, Martin On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Team, Whatever happened to this feature? Does it work in the latest release? I seem to remember the spec (version # anyone) saying js was required. Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 02:03 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support JS less :) sure +1 on that. Do you want to start a discussion on the dev list about org.apache.myfaces.ALLOW_JAVASCRIPT ? my friend, that's for you :) back to alaska ? or still in india ? Back from India, to Chicago :) ah I dude, I remember! :) you like it there ? -M Dennis Byrne On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Hi Matze, Am I the only one who feels the Tiles support and javascriptless feature should officially be retired ? To my knowledge these haven't worked well since the good ol' 1.0.9 days :) Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 01:40 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support it is this clazz org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl To be honest, you should try Facelets instead of Tiles for templating a JSF app -Matthias On 10/26/06, Michael Südkamp [EMAIL PROTECTED] wrote: Hello, I wonder what is the status of the tiles support? The myfaces-examples are still at version 1.1.1 and the included tiles web-app will not run with the the 1.1.3 libs (and probably also not with 1.1.4) (java.lang.ClassNotFoundException: org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl). The wiki topic at http://wiki.apache.org/myfaces/Tiles_and_JSF is also not up to date. Can anyone help me how to set it up? Michael -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT
The newest JSF-RI release (1.2_03) does not emmit anymore JS according to Ed. Only exception is the command-link... and for that one I discussed a possible solution with Ryan, which will be tried sometime soon... regards Alexander and: JS-free pages are definitely necessary... -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 8:14 PM To: MyFaces Development Subject: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT Hold on with Tiles support - it works without problems even in the current MyFaces-version. Javascript stuff - yes, we need javascript. No way round it, except you use only command-buttons. regards, Martin On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Team, Whatever happened to this feature? Does it work in the latest release? I seem to remember the spec (version # anyone) saying js was required. Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 02:03 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support JS less :) sure +1 on that. Do you want to start a discussion on the dev list about org.apache.myfaces.ALLOW_JAVASCRIPT ? my friend, that's for you :) back to alaska ? or still in india ? Back from India, to Chicago :) ah I dude, I remember! :) you like it there ? -M Dennis Byrne On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Hi Matze, Am I the only one who feels the Tiles support and javascriptless feature should officially be retired ? To my knowledge these haven't worked well since the good ol' 1.0.9 days :) Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 01:40 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support it is this clazz org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl To be honest, you should try Facelets instead of Tiles for templating a JSF app -Matthias On 10/26/06, Michael Südkamp [EMAIL PROTECTED] wrote: Hello, I wonder what is the status of the tiles support? The myfaces-examples are still at version 1.1.1 and the included tiles web-app will not run with the the 1.1.3 libs (and probably also not with 1.1.4) (java.lang.ClassNotFoundException: org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl). The wiki topic at http://wiki.apache.org/myfaces/Tiles_and_JSF is also not up to date. Can anyone help me how to set it up? Michael -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: mvn site speed
Why don't you do svn updates? and could it be that using mvn site it downloads mvn-plugins that somehow don't make it into the cache? Or has it to do with the deep dependency structure? regards Alexander -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:00 AM To: MyFaces Development Subject: Re: mvn site speed Yeah, it's kinda why I don't do many patches. It takes me 10 minutes to download a new svn snapshot, and 10 minutes to build it. In the good old days of cvs and ant, it seemed to go a lot faster. On 9/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: I'd love to have mvn speed improved for everything. I hate it to wait for 5min. until I can checkout my changes. regards, Martin On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Is it just me, or does mvn site take way too long to run? I can build the jar files faster, which is saying somethinig. Is there any way to improve the mvn site speed? Trying to work on documentation is kinda hard when turnaround time is 20 minutes. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Don't commit massive format changes with other changes
Or checkstyle to check compliancy... With the Eclipse and Idea plugins it can be checked very conveniently while working on the code. regards Alexander -Original Message- From: Jurgen Lust [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 7:10 PM To: MyFaces Development Subject: Re: Don't commit massive format changes with other changes We could put Jalopy in the Maven build process, I just finished writing a very simple plugin for it, for the internal framework I'm setting up at work... We've been using Jalopy for over a year now and we're very happy about it. Jurgen Op di, 19-09-2006 te 18:56 +0200, schreef Mario Ivankovits: Hi Martin! Oh my, I'm going under cover! This has started the single longest discussion on the mailing-list the last time ;) I hoped you already discussed it :-), and regarding to http://wiki.apache.org/myfaces/MyFaces_Developer_Notes this is the case. The decision was to use Suns Java Code Conventions (ok, I dont like it that much ;-) ), however, lets do it that way. Ciao, Mario
RE: Excel Export for Extended Datatable
True ... BUT imagine the doc you need to set up for the end-users: dependencies for tomahawk: ---list of jar-files--- if you want to use this component: add ---list of jar-files--- to the above list if you want ... and so on It might be easier to separate them into a entity and then document the individual entity's requirements... regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 2:58 PM To: MyFaces Development Subject: Re: Excel Export for Extended Datatable Well, the dependency wouldn't be a run-time-dependency, much more a compile-time-dependency. regards, Martin On 8/24/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: I think it would be a good idea to seperate such heavy components from Tomahawk... One reason I see is that maybe such libraries can be banned by corporate-managers. Users in such corporations could still use tomahawk... Others without the restriction just throw a few more jar-files into their webapps and can use the addon. regards Alexander -Original Message- From: Jurgen Lust [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 10:14 AM To: MyFaces Development Subject: Re: Excel Export for Extended Datatable What library will you use to generate the Excel output? POI? Should we really make this a dependency for Tomahawk? I think it would be better to put it in a different subproject. Some kind of ExportRenderKit, which could also contain PDF renderers using iText, for example. Jurgen Op wo, 23-08-2006 te 17:44 +, schreef Martin Marinschek: Yeah, exactly. If that works, I'd fancy it a lot more! regards, Martin On 8/23/06, Cagatay Civici [EMAIL PROTECTED] wrote: Hi Martin, Yes that seems like a better idea, so something like this one right? t:datatable id=tableId ... ... ... /t:datatable s:excelExporter for=tableId / This would render a button and onclick exports the datatable data to excel format. Cagatay On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hmm... My problem with our extended data-table is that it is much t overweight already. Couldn't we work with an extra component here, which has a for-attribute referencing a dataTable-component, and displays the button and on click the excel data for the dataTable? regards, Martin On 8/23/06, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, I've created a new feature for the datatable that allows exporting presented data to the excel format. Simply an excel button is placed on the datatable header and clicking on it makes an ajax request, a popup is displayed and excel file is presented. Following are the two screenshots; http://img206.imageshack.us/my.php?image=table17gs.jpg http://img80.imageshack.us/img80/3568/table7xm.jpg This was a requirement needed in my last project, I think it would also be useful if I integrate this for our extended datatable with an attribute. What do you think? Cagatay -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Cancelled: JavaOne MyFaces Committers/Contributors meeting
good point. I remember when I tried to replace some JARs inside a container (it worked) but our QA told me that this will cause problems @ customers`s side. They pay much money for a container and replacing JARs can cause loose of support form the vendor side. Even when the customers engineers agree to do it, management will give a thumbs down ;-) Anyway, let`s do the JSF 1.2 impl. Java EE 5 will not be part of production at big big big customers. so containers like Geronimo or OC4J (just to name two) will be able to take the MyFaces JSF 1.2 impl to their system Even though the big companies are likely to be late implementers, all AppServer-Companies have to get working NOW... It might need some marketing to convince some appserver-people to wait for MyFaces 1.2 regards Alexander
RE: Ideas, Ideas!
how about: http://wiki.apache.org/myfaces/WeNeedaGoodDemoApplication -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 1:21 PM To: MyFaces Development Subject: Ideas, Ideas! Hi everyone, Google SoC is coming up again - you have been notified already. We need project ideas - what does everyone want to have done for MyFaces, Tobago or ADF Faces? This is the existing list - nothing up for MyFaces so far: http://wiki.apache.org/general/SummerOfCode2006 regards, Martin
RE: Ideas, Ideas!
hmmm in one month it might be possible that somebody with prior knowledge of JSF could realize the usergroup-collaboration application. At least to the point where a working prototype exists... conditions: - prior JSF knowhow - fixed usecases - fixed requirements Somthing like an OS-version of http://www.meetup.com/ Our gain: we could also use it to organize regional JSF-usergroups ;-) The app could then be polished by regular OS-mechanisms... The other apps should be described better before starting the contest... but so far nobody has taken up the token in the wiki ;-( regards Alexander -Original Message- From: Gerald Müllan [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 1:51 PM To: MyFaces Development Subject: Re: Ideas, Ideas! I think we should do that comepition apart from School of Code You mean Summer of Code :) But apart from that you may be right. It depends on the amount of work the student has to put in. Work for SoC should be about one month! regards, Gerald On 4/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yeah, Carsten mailed me directly on that issue. He will donate 400 EUR. I think we should do that comepition apart from School of Code Maybe a winter or autumn code school ? I'll try to find some more donations... -Matthias On 4/19/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: how about: http://wiki.apache.org/myfaces/WeNeedaGoodDemoApplication -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 1:21 PM To: MyFaces Development Subject: Ideas, Ideas! Hi everyone, Google SoC is coming up again - you have been notified already. We need project ideas - what does everyone want to have done for MyFaces, Tobago or ADF Faces? This is the existing list - nothing up for MyFaces so far: http://wiki.apache.org/general/SummerOfCode2006 regards, Martin -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com -- Gerald Müllan Schelleingasse 2/11 1040 Vienna, Austria 0043 699 11772506 [EMAIL PROTECTED]
RE: idea regarding components
Do you mean replicating the tomahawk-components or different components under the tomahawk-sign? regards Alexander -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz Sent: Tuesday, April 18, 2006 1:41 PM To: dev@myfaces.apache.org Subject: idea regarding components Ok lets start the discussion. Since I´ve had to mess around again with the very cumbersome component api, and I still do not like it. I have an idea. I am not too familiar with facelets yet, but it seems like a good thing to bring the component programming forward for html centric components. How about a separate tomahawk-facelets project to ease this burden. I know those components would limit themselves in the usage with facelets but it would ease the programming a lot and probably would help people to jumpstart into component programming.
