Hello and introducing myself
Hello, my name is Arash Rajaeeyan I am currently located in San Francisco California. have been doing web development mostly on Java platform using open source technologies and my favorites are Apache tools! I hope I can contribute into this project, these are some stuff I am interested to add, if already doesn't exist and no body else is working on them: 1) full HTML5 (No Flash) support for rooms 2) keeping track of users login/logout attendance in rooms feel free to add me on linked-in https://www.linkedin.com/in/arashr
Re: OT: Oracle buys Sun
I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan
Re: OT: Oracle buys Sun
Oracle is a bigger competitor for IBM, has a more aggressive strategy and much less committed to open source,for example they have promised to open source Oracle ADF RC for nearly two years, (Apache RCF) but you can't see any progress. now Oracle will have the most complete software stack even more complete than Microsoft! although MySQL was very popular but it was not a direct competitor of DB2 (But Oracle is) and Solaris and AIX had their own customers, Sparc and Power platform had their own market share two, but now with popularity of Oracle DB, Oracle can boost Sparc and Solaris sale, and get more market share from IBM. in software market because of Strong position of Oracle, they may need less commitment to open source and open standards. cheers Arash On Mon, Apr 20, 2009 at 8:59 AM, Alan Hancock suddenrush9...@gmail.comwrote: What would IBM move to? Why would Java be any different with Oracle from IBM's perspective? -Alan via iPhone On Apr 20, 2009, at 10:25 AM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: JSR 299 / WebBeans - Expert Group
I am also very interested to have a full SE version of open web beans.any one here has checked Spring RCP ? Spring has a full stack competing with Java EE stack. they have also a solution for RCP and Fat Clients, an SE version of JSR 299 can attract lots of Spring developers, the EE dependent one will not be much interesting to them. On Thu, Apr 16, 2009 at 9:13 AM, James Carman jcar...@carmanconsulting.comwrote: On Thu, Apr 16, 2009 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Bob originally was interested in having IOC for SE also. But from what I've seen so far, he is imho one of those who requests that all the annotations should go under javax.se. To me this sounds more like 'oh this thing can't beat guice, so it should be for EJB only which we do not use anyway' ... So, why write a spec that's loosely based on Guice (a lot of concepts look similar; along with Seam) when it can't be used in place of it? That seems silly. We should strive for the best all-around IoC paradigm for Java, regardless of where it's running. It should have hooks for different scopes (similar to Guice and Spring and HiveMind, etc) -- Arash Rajaeeyan
Re: @Resource handling
can we assume ordinary java objects also have a place on JNDI tree? just as EJB 3.1 components names have become standard? that's some thing we can propose to be added web-beans (Java Dependency Injection) standard. On Fri, Mar 13, 2009 at 12:30 PM, Matthias Wessendorf mat...@apache.orgwrote: On Thu, Mar 12, 2009 at 10:34 PM, Mark Struberg strub...@yahoo.de wrote: Hi! The (EJB centric) Spec of @Resource says that the resource will always be looked up via JNDI [1]. I guess mainly because the whole J2EE stuff is really JNDI centric. Otoh in environments where no or only a read-only JNDI context is available, do we like to allow @Resouce also? I think, that I'd go for it -M I know this feature from Spring and I must say I love it. You can simply write a Bean and inject it via @Resource even without JNDI, So for Spring @Resource is more or less an alias for @Autowired (which is ~ our @Current) I'm not really sure how to interpret the section 5.12.1 of the spec. LieGrue, strub [1] http://java.sun.com/javaee/5/docs/api/javax/annotation/Resource.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Arash Rajaeeyan
Re: @Resource handling
Hi Mark, correct me if I am wrong. as 2009-01-22 the new name for web-beans is Java Contexts and Dependency Injection JNDI is a mechanism for naming and discovery of Java Objects in a distributed system. it lets components (complex heavy objects) to be discovered with a mechanism other than their Java Class name or Java Object pointer. since lots of systems are not distributed and run on single JVM, that distributed java objects parts makes no sense. but: in DI frameworks like Seam and Spring a component can be given an alias name other than it's class name. now if a developer wants to move from SE to EE (for example he may use SE for unit test, and EE for deployment, or current project size may not justify EE environment) changing the names may become painful if they need to be changed. if some naming mechanism compatible with EJB 3.1 JNDI names are used, it may help this change. putting objects in JNDI directory is not neccessary, but a a place for them on JNDI tree, (when program is deployed in EE) may be very usefull. Regards Arash Rajaeeyan On Fri, Mar 13, 2009 at 12:40 PM, Mark Struberg strub...@yahoo.de wrote: Hi Arash! Currently the spec imho only says that the Manager has to be exposed via JNDI. I personally don't see the benefit if we add all things to JNDI but I'm not a big EJB wizard. Why do you like to have it? Can you give us a sample where it would be an advantage? txs and LieGrue, strub --- Arash Rajaeeyan arash.rajaee...@gmail.com schrieb am Fr, 13.3.2009: Von: Arash Rajaeeyan arash.rajaee...@gmail.com Betreff: Re: @Resource handling An: openwebbeans-dev@incubator.apache.org Datum: Freitag, 13. März 2009, 10:03 can we assume ordinary java objects also have a place on JNDI tree? just as EJB 3.1 components names have become standard? that's some thing we can propose to be added web-beans (Java Dependency Injection) standard. On Fri, Mar 13, 2009 at 12:30 PM, Matthias Wessendorf mat...@apache.orgwrote: On Thu, Mar 12, 2009 at 10:34 PM, Mark Struberg strub...@yahoo.de wrote: Hi! The (EJB centric) Spec of @Resource says that the resource will always be looked up via JNDI [1]. I guess mainly because the whole J2EE stuff is really JNDI centric. Otoh in environments where no or only a read-only JNDI context is available, do we like to allow @Resouce also? I think, that I'd go for it -M I know this feature from Spring and I must say I love it. You can simply write a Bean and inject it via @Resource even without JNDI, So for Spring @Resource is more or less an alias for @Autowired (which is ~ our @Current) I'm not really sure how to interpret the section 5.12.1 of the spec. LieGrue, strub [1] http://java.sun.com/javaee/5/docs/api/javax/annotation/Resource.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: [jira] Created: (OWB-62) Refactor web-beans.xml to beans.xml
nice idea mark we can also discuss this in specification list, this is the benefit of parallel implementation of spec in Apache, they may not notice (or don't care about!) some existing problems, On Sat, Jan 24, 2009 at 4:33 PM, Mark Struberg strub...@yahoo.de wrote: But Aresh is right. So as we have to fulfil the spec (which really requires beans.xml now) and also like to be applicable for a lot of situations, we may add a kind of OpenWebBeansConfiguration class which reads this name (and maybe a few other settings in the future) form an openwebbeans.properties from the classpath. LieGrue, strub --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Sa, 24.1.2009: Von: Gurkan Erdogdu gurkanerdo...@yahoo.com Betreff: Re: [jira] Created: (OWB-62) Refactor web-beans.xml to beans.xml An: openwebbeans-dev@incubator.apache.org Datum: Samstag, 24. Januar 2009, 13:56 Hi Arash; We will just apply the specification requirements. Thanks; /Gurkan From: Arash Rajaeeyan arash.rajaee...@gmail.com To: openwebbeans-dev@incubator.apache.org Sent: Friday, January 23, 2009 9:28:03 PM Subject: Re: [jira] Created: (OWB-62) Refactor web-beans.xml to beans.xml Doesn't this make conflict with Spring bean.xml ? it looks like it is in Spring roadmap to become a light weight EJB 3.1 container, it may be possible in future that both web-beans and spring containers are allowed together. On Fri, Jan 23, 2009 at 9:15 PM, Mark Struberg (JIRA) j...@apache.orgwrote: Refactor web-beans.xml to beans.xml --- Key: OWB-62 URL: https://issues.apache.org/jira/browse/OWB-62 Project: OpenWebBeans Issue Type: Bug Reporter: Mark Struberg Assignee: Gurkan Erdogdu The term WebBeans has completely removed from the final PR spec and also the xml config files name has changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: [jira] Created: (OWB-62) Refactor web-beans.xml to beans.xml
Doesn't this make conflict with Spring bean.xml ? it looks like it is in Spring roadmap to become a light weight EJB 3.1 container, it may be possible in future that both web-beans and spring containers are allowed together. On Fri, Jan 23, 2009 at 9:15 PM, Mark Struberg (JIRA) j...@apache.orgwrote: Refactor web-beans.xml to beans.xml --- Key: OWB-62 URL: https://issues.apache.org/jira/browse/OWB-62 Project: OpenWebBeans Issue Type: Bug Reporter: Mark Struberg Assignee: Gurkan Erdogdu The term WebBeans has completely removed from the final PR spec and also the xml config files name has changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Arash Rajaeeyan
Swing Renderer
hi what is your idea about Swing Render kit? benefits may include: 1) same programming model for both desktop and web 2) ability to test programs much faster on desktop outside of web container Arash
Re: [New Incubator Project Help - WebBeans Spec Implementation]
Hi I am not a champion, and not an official MyFaces member, but I am willing to help in development, design, documentation, ... On Fri, Oct 3, 2008 at 6:19 PM, Matthias Wessendorf [EMAIL PROTECTED]wrote: FYI -- Forwarded message -- From: Gurkan Erdogdu [EMAIL PROTECTED] Date: Fri, Oct 3, 2008 at 4:11 PM Subject: [New Incubator Project Help - WebBeans Spec Implementation] To: [EMAIL PROTECTED] Hi to all; My name is Gurkan Erdogdu. I have been implementing the Web Beans Specification - JSR-299, EDR-1. 90% of the specification code is completed with its unit tests. I want to denote my working for the Apache Foundation, because I am the believer of the open source. As an open source developer, I developed open source JBoss Cache IDE for a while ago, as a committer of the JBoss IDE. After completing the EDR-1(in a couple of weeks), I will be synchronized with the next revision of the specification when it is available. I have read the pages and doumentation about the how incubator project is proposed and accepted by the foundation. I understand that, I have to find a Champion to further insist my project. Moreover, lots of documentation mixes my mind a little that how I will proceed. Help is very appreciated for taking a part of this great community; Thanks for helping; Sincerely; Gurkan Erdogdu [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Arash Rajaeeyan
Re: Need a MyFaces Product Environment matrix.
I havea added an small matrix to the following wiki page: http://wiki.apache.org/myfaces/CompatibilityMatrix if any body is sure about any combination he/she may edit it till the jira issue is solved. regards On 4/18/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/18/07, Paul Spencer [EMAIL PROTECTED] wrote: Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. ... I suspect this need to be on the MyFaces site. Well... then... add it. :) Seriously, we're a 'commit then review' project, and documentation is unlikely to be controversial. If you think it needs to be done but don't have time right now, open a JIRA issue and maybe someone else will pick it up. -- Wendy -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
and may be thats because shale has chosen a different approach? On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi ! Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... We developed it under the MyFaces umbrella during the last months, we started with a tag base way until we reached the spring based solution we have now. So, thats why it's still here. We will see what the future brings. Ciao, Mario -- Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
may be you can use GWT compiler for client side validation as well, it is also under Apache 2 license. On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Arash Rajaeeyan
Re: Client-side validation - enhance to match server-side
the difference is with GWT, user can write java code for client side validation instead of JS. they can compile it with their own Java IDE. but I also agree that adding another dependency to MyFaces is not good, specially dependency to such a big project. On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
Re: MyFaces Fusion
I think the best way is to extend the bean scopes and add some other scope(s) for conversation or dialogs. I think in first proposal they said they want to take best practices of Seam, Shale, ADF, and other JSF based frameworks and find best practices for web development, and put them in web beans (JSR 299) it can be addressed in low level Servlet API but it can also be addressed in higher levels like JSF frameworks. On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? Btw. speaking of JSR 299, and conversations, isnt jsr299 just a glue specification of marrying ejb3 and jsf so that you can use ejb3 beans as managed beans? Regarding conversations and dialogs: This stuff really belongs into the servlet space just like session and request, which technologies then are built on top of such scoping is an entire issue. Lets face it 90% of all problems most people have in webapps stem from the fact that you cannot keep objects for a longer time without going through the problems a session scope causes for garbage collection and due to the fact that if you do not work on a pure jdbc base but on an orm base you either have to keep an erm open for your entire session with all related problems or you have to open it on request or even works on business case and then run into the usual merge problems most orm layers have (which is not solvable in a satisfying way anyway) The current already big number of various dialog systems which also keep something conversational open for object storage stem from the fact that this is a huge problem or has become a bigger one now that webapps seem to have moved towards orm layers where this problem becomes more problematic. Tackeling it on JEE level has been long overdue in my opinion especially because most of the usage and core patterns basically are tested by now. Craig since you are reading this, any idea if the servlet specs will be opened to scopes/conversations in the next specifications? Werner -- Arash Rajaeeyan
Re: [POLL] Sort out of MyFaces Fusion Naming candidates
my poll: - Kleber - Chasb - Simplex - Platypus On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Ok, here we go. This is a poll where I hope that we can sort out the most of the names below (shouldn't be that hard ;-), afterwards I hope we are stripped down to max 4 names where we can start a vote then. Thanks for your time! Just remove the names you don't like, I'll try to sum up those decisions on the wiki page then. == Candidates == * Apache MyFaces Connections * Apache MyFaces Vista * Apache MyFaces Salida * Apache MyFaces Defender * Apache MyFaces Seamless * Apache MyFaces Mergence * Apache MyFaces Accretion * Apache MyFaces Collective * Apache MyFaces Aurora * Apache MyFaces Concerto * Apache MyFaces Orchestra * Apache MyFaces ease * Apache MyFaces Snug * Apache MyFaces Rush * Apache MyFaces Salida * Apache MyFaces Piletra * Apache MyFaces Kleber * Apache MyFaces Sepia * Apache MyFaces Chasb * Apache MyFaces Rapid * Apache MyFaces Custos * Apache MyFaces Coire * Apache MyFaces Simplex * Apache MyFaces Transit * Apache MyFaces Tenere * Apache MyFaces Memini * Apache MyFaces Memento * Apache MyFaces Custos * Apache MyFaces Coire * Apache MyFaces Simplex * Apache MyFaces Transit * Apache MyFaces Tenere * Apache MyFaces Memini * Apache MyFaces Memento * Apache MyFaces Pure * Apache MyFaces Direct * Apache MyFaces Alta * Apache MyFaces Sublime * Apache MyFaces Platypus * Apache MyFaces Brevi Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
how can I see the result of this work? On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Sorry to jump in here again, I have been playing guinea pig the last week for marios work. All I can say is this thing now is highly usable by now. You can put a view controller under conversation scope (not a shale one yet, you will lose the callbacks) and simply work on the stuff now like you would do in a rich client environment with an EntityManage, Hibernate Session open for the entire conversation. once you hit a point when you want to terminate, you can have the view controller/conversation invalidate itself or restart itself. Also binding component bindings onto such a conversation is taken care of, you can push them into a separate bean which you weave in by a scope of request and aop:scoped-proxy, then you basically get a fresh view onto your backend component bindings at every request. To sum it up, I just almost finished a first full master detail crud ( I have done several details forms before) The master form has about 30 lines of core code, excluding the setters and getters already dealting with dao calling, handling the query part etc... and adding a detail was a matter of one hour of figuring out which patterns work best and a few minutes of implementation handling new update and delete. The objects you work with always are the same the orm layer accesses, so a simple update ends up normally with entitymanager.flush(); And btw. bindings for hibernate and jpa already are in place... All I can say is a lot of thanks to mario for this, this is a killer... I think he has found the right mix of exposing the api and trying to automate. Seam while being excellent and Gavin was entirely correct with his approach of keeping the entitymanager open for a conversation, automates and hides way too much for my taste. One example is that it takes away the control how you connect the master and the detail, and in the end breaks the Tomahawk table that way. Gerald Müllan schrieb: Mario, i am feeling very confident that this will be a great addition to MyFaces in the near future. Through many lessons learned, I can admit that using Spring + JSF together makes up a powerful combination. Tying the new Spring/MyFaces-Conversation scope to JSF brings us beneath a seam-approach, but with less burden. I am quite curious about using the sample-app! As i believe, the sandbox stuff will be removed, after fusion will be quite stable. I also agree that it should have been discussed on the list, but ok it is done now. Next time devs should be informed before such a big commit takes place. cheers, Gerald -- Arash Rajaeeyan
Re: MyFaces Fusion
thank a lot mario, I have started to give it a try. hope I can learn it fast and write about it soon. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
nice demo, dose any documentation exist any where to start? (other than this example) On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! nice demo, hehe, dont lie ;-) dose any documentation exist any where to start? (other than this example) Unfortunately no, not yet. But I'll start one soon. Ciao, Mario -- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1546) Find a new name for Apache MyFaces Fusion
another Idea using name of foods people cook and eat when they are in hurry, I eat fish tuna or omelet when I don't have time too cook! may be the name brings similar idea in mind to developers. Tuna, Grill, Omelette or (omelet), Sandwich, Snack, Chips, Sausage, ... Add Apache MyFaces to the begging if neccessary On 2/28/07, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476388] Mario Ivankovits commented on MYFACES-1546: --- some more MyFaces ease MyFaces Snug MyFaces Rush Find a new name for Apache MyFaces Fusion - Key: MYFACES-1546 URL: https://issues.apache.org/jira/browse/MYFACES-1546 Project: MyFaces Core Issue Type: Task Components: General Reporter: Mario Ivankovits This jira is to collect new names for Apache MyFaces Fusion so far: Apache MyFaces Connections Apache MyFaces Vista Apache MyFaces Salida Apache MyFaces Defender Apache MyFaces Seamless Apache MyFaces Mergence Apache MyFaces Accretion Apache MyFaces Collective Apache MyFaces Aurora Apache MyFaces Concerto Apache MyFaces Orchestra -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Arash Rajaeeyan
Re: MyFaces Fusion
I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. If you use seam only for conversational control, yes then you can replace it, but seam has a lot of other added value which sometimes is a good supporting layer sometimes you do not need it, fusion has a dedicated scope, which is not quite the same as seam or currently existing dialog systems (but current dialog systems can use fusion as provider for their scope control, with the added value of getting full orm control as well) -- Arash Rajaeeyan
Re: MyFaces Fusion
Thanks mario, (and Werner) thats this is more than enough! On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. O-K I'll try: For the installation you have to configure the conversation scope in spring, for this you could have a look at fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml As might see, the conversation scope is configured using an advice, the persistentContextConversationInterceptor. This interceptor holds the entity manager for a conversation and is responsible to configure the thread. Every bean configured in conversation scope (using scope=conversation) will get a new entity manager. If you used spring before, your knowledge about daos wont change. Each conversation bean has to have the aop:scoped-proxy/ marker. This creates a proxy so that - even if you end a conversation - you can work with this bean - but on an new instance then. You can use the conversation scoped bean directly as your backing bean for the view, this is the common case if you have to deal with a single page only. If you have a wizzard like pageflow you'll typically create a conversation scope bean which you inject into your request scope backing bean then. The method in your conversation bean which will issue an update has to be annotated with @Transactional - you can change your entites in not annotated methods too, but then they are not flushed - the flush is delayed unit a @Transactional method has been invoked. That way the entity manager will issue a commit() at the end of the method. Tha can also be the point where you end a conversation, from within the conversation bean you can access the current conversation using Conversation.getCurrentInstance() The conversation can also be invalidated(), which means the next access to the bean instance will see an new empty one. There are strategies to restart a conversation too. The point is that you use the (well known) strategies of spring to get access to the entity manager, and in JPA they are the standardized. Fusion just configures spring so that it will see the associated entityManager for the to-be-invoked conversation. I am not sure if I manged to make things clearer now - all in all its the spring configuration which you have to make correct, afterwards there are just a handful of patterns which you should follow to make the most use out of fusion. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? On 2/28/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) Don't forget about the conversation scope implementation in Trinidad, too :-). Craig -- Arash Rajaeeyan
Re: MyFaces Fusion
I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
Re: MyFaces Fusion
I can send a working copy to your private email. if you want. zubin is going to use it in his book. I am changing it each day to make it easier for developers learning MyFaces. On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
I think a version number which is more similar to JSF standard versions will be much easier for beginners. and less confusing On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer -- Arash Rajaeeyan
Re: [Help - Translation] JSF 1.2 Impl found - Apache License ?
by the way why don't you see this one: http://www.apusic.com/en/ On 1/12/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: hi Matthias, try using this site for translation from Chines to English (or to German) http://babel.altavista.com/ On 1/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello, I am searching for sb. able to translate Asian languages (I think Chinese). The reason: By accident I found a JSF 1.2 impl, which seams to be open source at least that page says that: http://www.operamasks.org/Licence.jsp The main page is http://www.operamasks.org/ The page is owned by a company (selling/providing containers) http://www.apusic.com/ In case of Apache 2.0 License, we can speed up your implementation. In case of not, good to see a new version of a JSF Impl (not only sun, myfaces and ibm) Thanks! Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController). then what will happen to users who use Seam or future WebBean with MyFaces? as you may know seam also has its own phase listener and bean managment facility. can seam users also continue using myfaces? (seam has its own conversation mechanism, http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html) will nested conversations also be allowed? On 12/19/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Our plan was to implicit start a conversation as soon as a conversation been will be created through spring. Well, to know which conversationContext we are currently working in (this context is required for multiple window awareness) we have to add a request parameter to every rendered url. This already works pretty well, BUT one has to ensure that the s:startConversation tag is the very first on a page using conversations to allow the system to configure itself appropriate so that the url parameter will be appended. At least, the s:startConversation has to be before e.g. the form stuff. Now, with implicit started conversations this is not that easy any more. I see two solutions: 1) still support the startConversation (in addition to the implicit started one for sure). In fact I'll keep backward compatibility anyway, so this will happen anyway. 2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController). If this bean is in conversation scope (or one of its injected properties if you have request scoped backing-beans - like me ;-) ) this would have started a conversation then and the system is fine again. What do you think, would someone see such a standardization as a bad thing? IMHO having such a view controller concept would help much (not only for conversations), e.g. we too can have those prerender methods etc we often would like to have. Ciao, Mario -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
Hi Since jacob is also here, it is a long time that some components like tree don't work well with facelets, is resolving the issues on the plan? On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Oh, thanks! Hi Jacob! how's JSF 1.2 coming along btw? What do you mean? As far as I can see JSF 1.2. do not introduce any new (flash or conversation) scope. So (IMHO) our solution works with JSF 1.2 too. If you mean how far our (MyFaces) JSF 1.2 implementation is ... well ... then I have to say there is another team working on it, I don't know. Ciao, Mario -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
Thanx Matthias, very useful link, but I meant the old tree component not tree2, which people who need a tree table should still use it (according to myfaces web site) On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: http://www.jroller.com/page/plainoldweblog?entry=use_tomahawk_tree2_and_ajax4jsf On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: at least here is a famous blog, which shows the usage of tree2 and facelets (with ajax4jsf) On 12/19/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Since jacob is also here, it is a long time that some components like tree don't work well with facelets, is resolving the issues on the plan? On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Oh, thanks! Hi Jacob! how's JSF 1.2 coming along btw? What do you mean? As far as I can see JSF 1.2. do not introduce any new (flash or conversation) scope. So (IMHO) our solution works with JSF 1.2 too. If you mean how far our (MyFaces) JSF 1.2 implementation is ... well ... then I have to say there is another team working on it, I don't know. Ciao, Mario -- Arash Rajaeeyan -- 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 -- Arash Rajaeeyan
any one using Facelets + JSF 1.2 RI + Tomahawk here?
Hello I am using Facelts + Tomahawk + JSF 1.2 RI the number of components which are not working correctly or don't work at all has surprised me. to name a few inputHTML and commandNavigation2 which are very obvious components, don't work at all ! has any one had any similar problem? is there any special trick like the one for fileupload to get them to work on facelets? I am using Netbeans with facelt module with both Tomahawk 1.1.3 and latest daily SVN snap shots I have these lines at begining of my faces-config: application view-handler com.sun.facelets.FaceletViewHandler /view-handler /application and attached my web.xml best regards Arash Rajaeeyan ?xml version=1.0 encoding=UTF-8? web-app version=2.5 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; !--*-- !-- JSF Configurations -- context-param param-namecom.sun.faces.verifyObjects/param-name param-valuetrue/param-value /context-param context-param param-namecom.sun.faces.validateXml/param-name param-valuetrue/param-value /context-param !--*-- !-- Facelet Configurations -- context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.xhtml/param-value /context-param context-param param-namefacelets.DEVELOPMENT/param-name param-valuetrue/param-value /context-param context-param param-namefacelets.LIBRARIES/param-name param-value/WEB-INF/tomahawk.taglib.xml/param-value /context-param !--*-- !-- tomahawk configurations -- context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param context-param param-nameorg.apache.myfaces.ALLOW_JAVASCRIPT/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.DETECT_JAVASCRIPT/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.PRETTY_HTML/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.AUTO_SCROLL/param-name param-valuetrue/param-value /context-param !--*-- filter filter-nameMyFacesExtensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value /init-param init-param param-nameuploadRepositoryPath/param-name param-value/temp/param-value /init-param /filter filter-mapping filter-nameMyFacesExtensionsFilter/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/myFacesExtensionResource/*/url-pattern /filter-mapping servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping session-config session-timeout30/session-timeout /session-config welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list /web-app
swapImage component
swapImage component has no documentation at all, and its realted example is not working.since last revision is 2006-03-01 it looks like component is not deprecated.it looks like the developer is Thomas Spiegl would he or the one who is maintaining it tell me what is its status? and possibly some hints for documenting it?Arash Rajaeeyan
Re: MyFaces with Sun's JSF RI on Websphere5.1
hi roy,I am not sure but I think IBM has its own implementation of JSF not suns, http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13706717cat=28thread=75431treeDisplayType=threadmode1forum=472#13706717as you said, you are using jsf-ibm.jar in your project.On 11/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, Desperately in need of answers to make it work. 1)I am using WebSphere5.1 and RAD6 for IDE. 2)The jars i am using are :Tomahawk1.1.3.jar,jsf-api.jar,jsf-impl.jar. (Apart from the jars common-beanutils.jar,common-codec1.3.jar,common-collections.jar,common-digester.jar,common-lang.jar2.1,javax-jdom.jar,jdom.jar,jsf-ibm.jar,jsf-portletjar,jstl.jar,jstl_el.jar,standard.jar,saxpath.jar and common-fileupload.jar.) Please note i am not using myfaces-api.jar and myfaces-impl.jar my project wants to use only Sun's JSF RI.Can Tomahawk1.1.3 work withoutmyfaces-api and myfaces-impl.jar.?? 3)My application uses t:inputCalender and t:panelTabbedPane. 4)The exception that i get is :Nested Exception is java.lang.IllegalStateException: ExtensionsFilter not correctly configured. JSF mapping missing. JSF pages not covered. Please see: http://myfaces.apache.org/tomahawk/extensionsFilter.html 5) The web.xml is configured as : filter filter-nameextensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value descriptionSet the size limit for uploaded files. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB/description /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value descriptionSet the threshold size - files below this limit are stored in memory, files above this limit are stored on disk. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB/description /init-param /filter filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsp/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.faces/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping Can you please help me in this regard.How should i configure the extension filters or use any new jars.I am struggling to get this work. Best Regards, Pallavi The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Arash Rajaeeyan
development attribute in dojoInitializer
development attribute in dojoInitializer, is in DojoInitializerTag.java but it is not in TLD class, half documented in xdoc web site.is it removed or what?Arash Rajaeeyan
Re: Option for NavigationHandler to support viewIds as outcome
It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them.since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) RegardsArashOn 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,It's all about convention over configuration, and this concept is inturn very good for maintenance. Writing unnecessary configuration codeisn't.Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview andthis means, I'll go to overview.jsp2) I want to change this to go to overview_2.jsp3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change thenavigation-rule - where is the maintenance difference, I don't touchmy managed-bean?)4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF.Essence is - you don't have to change anything in your managed bean,youjust add configuration rules where necessary, but keep them out where unnecessary.regards,MartinOn 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app.WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps.But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration.And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket.The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle navigation via annotations. I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations.Doing so would have the same effect as implementing the suggested approach -- it would be requiring the person developing the server side business logic to be intimately aware of view tier considerations like what view should I show next?. Doing so makes it basically impossible to reuse business logic in scenarios like: * Migrating a non-AJAX app to be AJAX-enabled * Using the same business logic for REST-based or SOAP-based web services In short, I believe that requiring the developer of an action method to know anything about what the view tier will do next is a ***very*** bad idea. You might note that the Shale Tiger Extensions have no provision for annotation based navigation.That is a deliberate design choice, not one based on limited development time :-) regards, Martin Craig--http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- Arash
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF.what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet)I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David,@breaking tool support: yes, that's true, and is something that mightor might not be of interest to developers.@application size: For an application with 2000 views, we'redefinitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developersassigned to them the normal navigation system should be used.Having the option of not using the default navigation system forsmall, simple applications is something positive, though. regards,MartinOn 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output.There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them. since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) Regards Arash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, It's all about convention over configuration, and this concept is in turn very good for maintenance. Writing unnecessary configuration code isn't. Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp 2) I want to change this to go to overview_2.jsp 3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change the navigation-rule - where is the maintenance difference, I don't touch my managed-bean?) 4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF. Essence is - you don't have to change anything in your managed bean, youjust add configuration rules where necessary, but keep them out where unnecessary. regards, Martin On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate arethe same whether there is one developer performing multiple roles, ordifferent developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case.Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin,First thanks for taking time and answering me.Believe me or not, the concept is hard to grasp for lots of developers, at least for people in my country who are not as wise and intelligent as people in Germany and Austria, lots of developers are not Computer Science PHD and most of them are not even college educated!I remember 10 years ago, when we were developing codes in C++, most of our time was spend on finding memory problems caused by illegal pointers created by freeing an object in wrong places. Now with garbage collection in java it is years that I haven't seen the problem, although average knowledge of developers is much lower now because of high demand in IT industry.May be this phrase is wrong, but it think a good development framework (especially those who are designed for ease of use) should not let developers make mistakes.I remember when I was in guidance primary school, our Pascal and C programming teacher decided not to teach us about Labels, because he knew that some of us had some experience in GW-Basic programming and we can't get ride of GOTO, and we can't ever learn structured programming, now I think the same case is about this NavigationHandler mechanism, it is like goto in structured languages.RegardsArash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Arash,I don't think we're in the JSF space to force developers to dosomething in a certain way. The navigation system of JSF is good, it'sbeen devised with decoupling in mind, and you might want or not want that for your application - I don't think that the rationale behindthis is hard to grasp for anyone. So your sentence about the deeprationality behind the navigation mechanism is a bit overblown... Especially, as with what Ernst suggested, you can still configure -you just don't have to!There is a host of web-frameworks which don't build on this decouplingout of the box - so why not giving the developer the option to do things in the way they're used to? Mind it, I'm not one of the guyswho hate configuration files, and I don't have anything againstfaces-config.xml. There are people out there who want to reduce it toa bare minimum, though, and I don't see why one shouldn't. Enough said, there are pro's and con's, and I do believe that anoption won't hurt anyone, if it's nicely implemented.regards,MartinOn 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF. what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet) I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David, @breaking tool support: yes, that's true, and is something that might or might not be of interest to developers. @application size: For an application with 2000 views, we're definitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developers assigned to them the normal navigation system should be used. Having the option of not using the default navigation system for small, simple applications is something positive, though. regards, Martin On 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead
Re: javadoc
Hi Sebastian,there are 1) Java Docs2) wiki pages3) maven XML documents which generate web site of myfacesthese should be updated and synchronized together, I have started to work on wiki, I hope when I finish we can start synchronizing javadocs and web pages. if you are interested to help you are very welcome we can divide the work between our selves.also soon there will be a book about MyFaces http://www.apress.com/book/bookDisplay.html?bID=10179On 10/30/06, Sebastian Menge [EMAIL PROTECTED] wrote: HiI've subscribed to this list to post just one remark/question.Myfaces is a great implementation. Another example of an opensource effort that will soon be better than the RI.But! ;-)Please take more care on documentation. The javadoc is really really ajoke.Please dont mind. I want to use myfaces in my setting and if I could I also would contribute something.But good documentation is for me about 50% of a good project.I was looking for _anything_ useful regarding the navigationPanels. Noway. There are some tags, there are some classes, no explanations, no cross references between tags and classes etc.There are a few postings on [EMAIL PROTECTED] or some forums, there are somewikipages. But such things should really be documented at some centralplace like javadoc ... Sorry, after nearly a week of wasting time with undocumented things, igot a little bit angry.Please take this as a suggestion to make myfaces a high quality project.Thanks alot for all the good work, Sebastian.PS I know, writing docs is not so exciting as implementing features ornew components. And if you want to do it good, its really difficult. (Ithink even more difficult than programming, because you have to think like your potential reader(s) and not only like the machine ...). Atlast a good documented API can give you a good feeling to... Really :-)To be a little bit constructive: There is a good text on this topic from Sun. Please read it and give it a try.http://java.sun.com/j2se/javadoc/writingdoccomments/ -- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
Hi Craig,so you think it is better that we have another implementation of lifecyles for JSF portlets,(from scratch or using decoratore around current class) which can support both ActionRequest and RenderRequest and map them to different neccessary phases of JSF, one mapping for those who get ActionRequest and another for those which only recieve RenderRequest. am I correct?On 10/29/06, Craig McClanahan (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12445431 ]Craig McClanahan commented on MYFACES-1383: --- Looking at this issue again, it seems to me that it would be better to recreate the FacesContext between the execute and render phases of the lifecycle. We would need to preserve messages and some other things, but nothing to difficult to preserve. This would allow wrappers to update their wrapping when the external context changes.I would recommend that this suggestion be implemented ... not just for consistency with the other bridges, but because the portlet lifecycle is different from a standard webapp lifecycle in one crucial respect.Consider the scenario where you have six portlets on a particular page, all created with MyFaces (yeah :-).On any given request, *one* of the six portlets will go through the Restore View through Invoke Application phases, while *all* six portlets will have the Render Response phase executed.Thus, it is important for portlet developers to understand that they need to be prepared to rerender their current contents at any time, whether or not they were the portlet that received this particular postback.The easiest way to do that is to treat a single portlet request as two JSF requests ... one for the execute part of the lifecycle, and one for the render part. And that, by the way, is why the Lifecycle API has these two subsets of the overall lifecycle split into two methods. FacesContextFactoryImpl issue using trinidad any myfaces core - Key: MYFACES-1383 URL: http://issues.apache.org/jira/browse/MYFACES-1383 Project: MyFaces Core Issue Type: BugComponents: Portlet_SupportAffects Versions: 1.1.5-SNAPSHOT Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17Reporter: nicolas kalkhof trinidad won´t run in a portlet environment. problem is, that FacesContextFactoryImpl does not extend ServletFacesContextImpl. therefore this is an internal myfaces core problem that could hopefully be fixed. stacktrace of the crashing portlet using myfaces and trinidad: javax.portlet.PortletException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:407) Nested Exception is java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender (MyFacesGenericPortlet.java:387) at net.portlets.logon.LogonPortlet.doView(LogonPortlet.java:88) --This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see: http://www.atlassian.com/software/jira -- Arash Rajaeeyan
Re: Option for NavigationHandler to support viewIds as outcome
I think this is a bad idea for following reasons:1) it is against the spec behaviour2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes 3) this make confusion between page names and outcomes (navigation events)4) I think outcomes and names of JSF pages should stay separate.JSF navigation is like an finite state machine (FSM) or finite state automaton, states are pages and outcomes are input to the automaton, this keeps modeling UI very simple. and also it makes it possible for formal verification of JSF application, with available tools.RegardsArash RajaeeyanOn 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote:Hi! At the moment when no navigation case for an outcome is foundthe navigationHandler decides to stay at the same view. I thinkan option for web.xml would be useful to tell the navigationHandlerif no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id.This idea was mainly driven by a lot of jsf-projects where I saw for eachview id:navigation-rulefrom-view-id*/from-view-id navigation-casefrom-outcomeviewId/from-outcometo-view-id/viewId.xhtml/to-view-idredirect//navigation-case ...which seems kind of unnecessary to mewhat do you think about that?regardsErnst
Component and tags documentation and wiki
Hello All,I want to synchronize the latest web site documentations and Wiki InformationI want to use the following headers and clean the wiki informationI hope if the quality of works was good, the result transferred to web site documentations to. I want to use following headers and mote information into them and complete the definition:[Component Name]DescriptionScreen ShotAPIUsageSyntaxConfigurationInstructionsAdditional Information ExamplesFAQKnown Bugsfirst: does any one has any objections?second: do you suggest another format?Arash Rajaeeyan
Re: calling authors
me 2I am also volunteerI don't have any experience using Tobago. I haven't used Shale in any real world project.but I have used the rest of component and some times applied some small changes in them. tell me what do you want in that article?what topics should be covered in what detail.On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:I am writing one on Trinidad for the German Java Magazine, maybe we can translate it later (deadline is december 20th or so)(I know I need to send you the portlet article too :) )-MOn 10/25/06, Kito D. Mann [EMAIL PROTECTED] wrote: Hello, I'm currently looking for people who are interested in writing great articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or Shale. If you're interested, please reply! ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com 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--Matthias Wessendorf http://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: calling authors
another idea comes into my mind, when I finished the article I can put it on wiki or post it to list, and let others edit it or send their suggestions.On 10/26/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: me 2I am also volunteerI don't have any experience using Tobago. I haven't used Shale in any real world project.but I have used the rest of component and some times applied some small changes in them. tell me what do you want in that article?what topics should be covered in what detail.On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:I am writing one on Trinidad for the German Java Magazine, maybe we can translate it later (deadline is december 20th or so)(I know I need to send you the portlet article too :) )-MOn 10/25/06, Kito D. Mann [EMAIL PROTECTED] wrote: Hello, I'm currently looking for people who are interested in writing great articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or Shale. If you're interested, please reply! ~~~ Kito D. Mann ([EMAIL PROTECTED] ) Author, JavaServer Faces in Action http://www.virtua.com 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 --Matthias Wessendorf http://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: Jira Probleme
so this may be even more interesting for you:http://en.wikipedia.org/wiki/German_AmericanOn 10/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I expected that :)happy to read German content, when being in the states ;)-MOn 10/24/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, It was meant for Manfred, he just sent it to dev by mistake! Z. On 10/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think something went wrong here :) or at least we wanna ensure that every user can read (w/o to translate) your mail. PS: Alle Apache Server waren down, wegen server-umzug. people.apache.org immer noch. Jira wird wohl wieder. Keine Sorge :) -Matt On 10/24/06, Andreas Berger [EMAIL PROTECTED] wrote: Hallo Manfred, da du der Admin von Myfaces Jira bist, wollt ich dir nur bescheid geben, dass ich seit gestern keine Jira Mails mehr bekomme (und ich habe auch einen anderen aus der dev-liste gefragt, der sie auch nicht bekommen hat). Demnach weiß noch keiner dass ich eine Reihe von Patches hochgeladen habe, vor allem für dien CR [1].Bspw. kam für die Einstellung des Patches für [2] keine Mail. [1] http://issues.apache.org/jira/browse/MYFACES-1434 [2] http://issues.apache.org/jira/browse/MYFACES-1454 Vielleicht könntest du mal nachschauen, ob da noch alles richtig läuft. Danke, Andreas -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias Wessendorfhttp://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com-- Arash Rajaeeyan
examples
Are we going to have myfaces examples in downloads page again?the text on http://myfaces.apache.org/gettingstarted.html is confusing for new comers when they find out there is no example to downloads. and it may be hard for them to get source from svn and make examples them self. Arash
Re: panelNavigation bug in Firefox 2.0 RC3
why not report this bug to firefox developers? On 10/25/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: this same problem (of needing nbsp to display empty table cells) occurred back in the days of Netscape 4.7. It would suck if they've regressed back to that. Back then, we had to solve this by having a special ResponseWriter. The special ResponseWriter would detect if a TD was followed by a /TD with no intervening non-whitespace character, and automatically insert an NBSP for netscape. --arjuna On 10/24/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Simon, I've seen similar issues to this but not yet with Firefox 2.0. It can be a pretty annoying issue because placing text into something that didn't contain text before may alter its dimensions--even if a specific width and height are specified. When that was the case, I believe we worked around it by specifying either a line-height: 1px; style or possibly an overflow: hidden; style. If the container is larger than a character, then there is nothing to worry about. On a somewhat related note, I'm not sure the DOM structure of the tabs in the navigationPane are even in a format that is very flexible for alternative appearances. I'd be happy to see it restructured to be less reliant on tables--possibly even structured so the DOM elements actually overlap instead of having graphics to give the illusion of overlapping tabs. Thanks, Matt On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, There's a small bug with panelNavigation in tab mode in Firefox 2.0 (didn't check 1.5) where the tab borders are not rendered. I think it's because Firefox renders some elements only if they contain something. Since tabs structure only use some td for background image, it fails. I think I had the same problem with panelBox and I ended adding a small nbsp; I might have to check. Anyone else has experience with this or comments for the potential fix? Regards, ~ Simon -- Arash Rajaeeyan
Re: Re: Re: Formatting locale vs. translation locale
thanks adam useful hints as usual On 10/25/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, No, there isn't a conflict. Code looking for translations will all use UIViewRoot.getLocale(). BTW, for reading direction, we already have a RequestContext getReadingDirection() that can be overridden using trinidad-config.xml. -- Adam On 10/24/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Adam, let me clear that I think separating Formatting locale and translation locale is a very good idea. there are lots of methods in JSF to get current locale, my point is to make sure these methods don't return some thing in conflict with each other. for example we must make sure the other components on the page you mentioned are not searching for German translation of texts. the same concept can also be extended to direction, users whose language is written from right to left like Hebrew, Arabic and Farsi may prefer their menu, trees, tabs, etc to be right aligned, and behave how they expect even if the text is still in English. for example scroll bars in left side is common in right to left languages, and if your browser has put one scroll bar in left, and a JSF page displayed in the browser has put scroll bar in right side of the page it becomes very confusing. On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: Formatting locale vs. translation locale
Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: [PORTAL] Custom lifecycle?
Hi scott, you are right JSR 286 has non of these problems because they have added Resource Serving and Portlet filter concepts: PLT.13 page 67 Resource serving – provides ability for a portlet to serve a resource.. PLT 19 page 199 Portlet filter – allowing on the fly transformations of information in both the request to and the response from a portlet I think if want to add a filter for image and other resources, this should also do the job of ajax calls, and if use another method, we should still find a way for ajax calls and we will probably do same work twice On 10/24/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need
Re: [PORTAL] Custom lifecycle?
if we forget about ajax what about immediate, is there any facility in trinidad which shortcuts lifecycle? On 10/24/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need for filters altogether would be a good thing. Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
hey Mario, these gui builder components are great I think they may gain lots of attentionis there any way I can read more about them?On 10/15/06, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: create a component which creates the JSF tree based on beans and its annotations Key: TOMAHAWK-741 URL: http://issues.apache.org/jira/browse/TOMAHAWK-741 Project: MyFaces TomahawkIssue Type: New FeatureComponents: New Component Reporter: Mario Ivankovits Assigned To: Mario IvankovitsPriority: MinorThe component I'll going to add to the sandbox is the GUI Builder stuff I developed for FacesFreeway. The component name is dynaForm and I'll add it to the sandbox15 area as it requires annotations and thus java 5.0--This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see: http://www.atlassian.com/software/jira -- Arash Rajaeeyan
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
sorry for being impatient, I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! hey Mario, these gui builder components are great I think they may gain lots of attention is there any way I can read more about them?Nope, there is only the source and a simple example yet. If you checkout myfaces using the url [1] you'll get the sandbox15module of tomahawk too.Though, to checkout the sandbox15 module only use [2]I try to add more examples and a Wiki documentation as we speak, so hold on for a while :-)Ciao,Mario[1] https://svn.apache.org/repos/asf/myfaces/current[2] http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox15-- Arash Rajaeeyan
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
future will bring us ... lets beat ruby - hehe - just kidding ;-)hey why not? when the JSR 276 finished we can bring ease of use of Java Studio Creator to All java IDE's then users can just drag and drop their database tables or java bean or EJB intro JSF pages and have the application ready! as I understood your GUI builder components are an small step for you and myfaces but a giant step for JSF community for this target! ;-)On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! sorry for being impatienthehe :-) I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. Let's see how far we can go. For now I removed the persistence stuff,the master plan is to rework the persistence using ourconversationTag, but it should work with Seam too.Yea, and at the end there is still a mvn createApplication (or something like this) missing, it depends on the community what thefuture will bring us ... lets beat ruby - hehe - just kidding ;-)Ciao,Mario-- Arash Rajaeeyan
Question from project owners about 1.1 and 1.2 distribution numbering
Hi I am writing a guide for beginners on how to use MyFacesI have two questionsI want to know what will be package name for implementation of JSF 1.2 api on download siteis it going to be: myfaces-core-1.2.x ?if so will tomahawk branched to to two different versions one for running on JSF 1.1 and another for running on JSF 1.2 ?if answer is positive is tomahawk numbering going to be like this: tomahawk-1.1.x. (run on JSF 1.1) tomahawk-1.2.x. (run on JSF 1.2)Regards Arash Rajaeeyan
Re: who is in charge for JSR 301?
may be I don't get it correctly, but a good solution should cover both multi-part form and lifecycle concepts.On 10/12/06, Scott O'Bryan [EMAIL PROTECTED] wrote:Arash,Is this the multi-part form ExternalContext or the much simplified pre/post lifecycle stuff?ScottArash Rajaeeyan wrote: thank you Carsten, you may have seen the portlet patch of shinsuke for tomahawk, we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago. it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301 as an exprienced member of this group, do you have any guidelines for us? On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Yes, I'm in the spec group - but upto now I don't know who else from Apache is on. Carsten Matthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org ) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guys want.Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ -- Arash Rajaeeyan
Re: who is in charge for JSR 301?
thank you Carsten, you may have seen the portlet patch of shinsuke for tomahawk, we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago. it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301 as an exprienced member of this group, do you have any guidelines for us? On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Yes, I'm in the spec group - but upto now I don't know who else from Apache is on. Carsten Matthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet. I can jump on that if you guys want. Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ -- Arash Rajaeeyan
Re: who is in charge for JSR 301?
thank you Carsten,you may have seen the portlet patch of shinsuke for tomahawk,we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago.it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301as an exprienced member of this group, do you have any guidelines for us?On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:Yes, I'm in the spec group - but upto now I don't know who else from Apache is on.CarstenMatthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guys want.Michael Freedman is the Spec Lead and he is someone I work with on a regular basis.--Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.dehttp://www.osoco.org/weblogs/rael/-- Arash Rajaeeyan
who is in charge for JSR 301?
hello who is in charge for JSR 301 here? -- Arash Rajaeeyan
Re: Public API's not part of JSF
Hi Matthiasis there any classes in any of those packages now?On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi *The shared-impl is not really available in source. It's part of the shared. There is also a shared-tomahawk generation. Shared itself willnot be released. I wrote a small wiki page on [1] about shared.@Martin: 434 ?if so, we (Sean, Wendy and me) just spoke to some portlet guys at the hackaton...that goes against old code etc, maybe they help us on that.btw. discussion about MyFaces's shared stuff should go to [EMAIL PROTECTED],since trinidad is not really depending on it ;) Greetings from sticky Austin.-Matthias[1] http://wiki.apache.org/myfaces/Shared_-_impl_or_tomahawkOn 10/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Scott, we've had re-occuring discussions about a new commons-module. This would probably be good candidate for this. Additionally, I've still got to review a commit for a module by Shinsuke Sugaya, which is about portlet compatibility - maybe it would be good to put it there. regards, Martin On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Is there a place where we could store public API's that are not part of Faces in MyFaces?Would this be the shared-impl package?We'll likely need to support an interface to handle some of our filter functionality from a portlet.This interface would need be referenced by the MyFaces Bridge Portlet (in impl) and Trinidad Impl... Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces--Matthias Wessendorfhttp://tinyurl.com/fmywhfurther stuff: blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com-- Arash Rajaeeyan
Re: who is in charge for JSR 301?
I see name of Apache foundation thereso there should be some one from Apache!if it is not ADF, is there any one from Myfaces ?I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guyswant.Michael Freedman is the Spec Lead and he is someone I work withon a regular basis.ScottArash Rajaeeyan wrote: hello who is in charge for JSR 301 here? -- Arash Rajaeeyan-- Arash Rajaeeyan
Re: dynamic table columns et al
Hi MarioI think this sound pretty much like rubby on railsI don't know about other developersbut I think some people like this kind of components for making rapid web sitesome people hate these kind of components because the code is doings lots of thing implicitly and the code is not showing those behaviour.
lets see what Myfaces gods think about this.On 10/11/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!As some of you might know I've developed Faces Freeway [1].Well, I don't want to say that this project failed, but - beside - its
hard to maintain a documentation, it is also hard to provide a nicelooking, always working fully fledged simple way to the persistenceframework e.g. hibernate.BUT, there is one thing I'd like to donate to MyFaces.
The GUI Builder.The GUI Builder is responsible to instrument another component to viewselected properties out of an annotated Bean (EJB3).I'd like to let speak code (piece of[2]):ff:form var=blog uri=ejb:
blog.Blogh:panelGrid id=blog-layout columns=2 //ff:formThe above simply does the following:* Lookup a bean by its FQN (=blog.Blog)* Lookup a child component whose id is blog-layout (That is by
convention. The form's var is blog, so the target component has to beblog-layout)* invoke the GUI Builder to dynamically add the bean's properties to thegrid (in this case)At the end, the you'll see a page as if you have written many
outputLabel and input* components.The same goes for a table (piece of [3]):ff:form var=city uri=ejb:blog.Cityh:dataTable id=city-layout var=entity value=#{
city.fc.entities} rowClasses=tr1,tr2h:column id=data rendered=false //h:dataTable/ff:formThe same as above, just creates a table header and its columns. The
id=data column is optional, but allows you to have pre and post columns.Ok, I hope I made it clear what it do and how it works. Again - I'dremove any requirement to a persistence framework. It should just do the
dynamic stuff.The proposed name could be: dynaBean :-) (instead of ff:form)One possibility I still have on my todo list is to allow the user toselect the properties which should be shown.This makes sense if you have beans with many properties, but only a
handful of properties are relevant to your customer. Then you cancustomize them easily. Maybe also adding user defined properties whichare computed at runtime (maybe using BSF) are possible (not yet, but
thats the masterplan)A factory the user has to provide is responsible to store all thiscustomization stuff.Due to its nature this component relies on annotations, well, can workwithout, but its more fun. So it has to go to sandbox15 (is it
functional already?)What do you think?Ciao,Mario[1] http://facesfreeway.l3x.net/[2]
http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Blog.jsp[3]http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Cities.jsp
-- Arash Rajaeeyan
Re: MyFaces 1.1.4
although my vote is not counted but that's a good idea just be aware that there are some incompatibilities between those versions. although I don't think those effect trinidad but it is so good to upgrade and be sure those incompatibilities will not affect trinidad On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: anyone mind to use myfaces 1.1.4 instead of 1.1.2? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: [Jira] Portlet Issue
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and one
to the MyFaces Portlet_Support component. That should get us started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing. Hopefully
I'll be able to check it in soon.
Scott
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Hi scott,
my post was generally about portlet support.
you are right the second type method can be fixed by a wrapper which
implements HttpServlet and wraps Portlet.
I prefer to use a method which works in all portals JSR168, or WSRP and even
in future JSR 286, if some solution works for second type (Not Drived
Classes from HttpServlet) of portals it will work for first type (Drived
Portlet classes from HttpServlet)
I will test every thing with both kind of portals to make sure they both
work fine.
may be we can modify that MyFaces Bridge and add what ever we need to
support trinidad.
trindidad and tomahawk are both under myfaces, and many people including
myself are using both set of components.
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
To answer Mitthias, I'm going to be testing against Pluto and Oracle's
WSRP. I *MAY* add Gridsphere to the test since it's Websphere like.
Now, Arash, you are replying to a different issue. I noticed that
Tomahawk has added support for PortletFilters and I guess I jumped the
gun on wanting to use it. By removing dependencies on the wapper
objects in the filters, we can remove any dependency we have on the
implementation of the particular portal for now. Perhaps we may even
have to depend on our own bridge portlet which (like tomahawk) is
derived off of the MyFaces Bridge. The things that concerns me is that
never will the two run together in a portal environment if we do this.
I have a requirement to allow this stuff to run in a WSRP container
which is more like type 2 of your scenario. Therefore, I am flat
against using an implied implementation (like taking advantage of the
fact that WebSphere wraps httpServletRequest/Response objects. I
*don't* mind providing an interface with various adapters (for each
portal maybe) that could implement these wrapper objects as hopefully
well have something similar in the spec in a year or so.
That being said, while LifeRay is not of the first type you recomended,
someone familiar with the system should be able to provide a wrapper
object for LifeRay's PortletRequest implementation object.
Scott
Arash Rajaeeyan wrote:
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet
Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation
which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends
HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and
one
to the MyFaces Portlet_Support component. That should get us
started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing.
Hopefully
I'll be able to check it in soon.
Scott
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Hi yes it makes sense. you know the problem is Protlet is more limited than servlet so some Portlet Classes (say PortletRequest) have less methods and properties than their counter part (say HttpServlet) so the wrapper which implements Servlet class and has wrapped a portlet related class inside should return null or throw exception in some special cases. so these wrappers behaviour is not completely same as their http servlet counter parts. I don't know if this functionality are used any where in trinidad or not. as long as I find out in the codes there is no dependency on HttpServlet classes and in most places the JSF classes are used in trinidad. for example in most places FacesContext is used and not ServletContext so there is no problem in returning PortletContext in getFacesContext On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Yeah, that was my origonal thought. I'll reopen MYFACES-1448 which is a task to do just that. All we need is something simple to do the Non-Wrapper initialization code. It would need an init and a destroy as well as a pre-lifecycle and post-lifecycle call, but these could be done with the PortletContext, PortletRequest/Response classes. As for the wrappers, you get me wrong. I'm not wanting to tie myself to HttpServlet stuff at all. Here is my theory about moving the functionality of the wrapper objects to our existing ExternalContext wrapper. If we have an HttpServletRequest/Response then we can simply use the provided wrapper objects. If we don't then we would need to get the original request object and ExternalContext and wrap them overriding only the functionality we need to. The wrapped external context would return a wrapped PortletRequest/PortletResponse/PortletContext object of the appropriate (Action or Render) type. For dispatching your wrapper simply need to take the provided object's wrapped object and pass it into the superclass. Therefore, the external context references a wrapped PortletRequest and Response as well as it's underlying implementation. We'd have to be a bit careful when the objects switch from ActionRequests to RenderRequests, but this should be pretty easy to do. This would allow us to create wrapper objects without actually having them supported by JSR-168 or the need to cast to HttpServlet stuff. Does this make sense? Arash Rajaeeyan wrote: Hi scott, my post was generally about portlet support. you are right the second type method can be fixed by a wrapper which implements HttpServlet and wraps Portlet. I prefer to use a method which works in all portals JSR168, or WSRP and even in future JSR 286, if some solution works for second type (Not Drived Classes from HttpServlet) of portals it will work for first type (Drived Portlet classes from HttpServlet) I will test every thing with both kind of portals to make sure they both work fine. may be we can modify that MyFaces Bridge and add what ever we need to support trinidad. trindidad and tomahawk are both under myfaces, and many people including myself are using both set of components. On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote: To answer Mitthias, I'm going to be testing against Pluto and Oracle's WSRP. I *MAY* add Gridsphere to the test since it's Websphere like. Now, Arash, you are replying to a different issue. I noticed that Tomahawk has added support for PortletFilters and I guess I jumped the gun on wanting to use it. By removing dependencies on the wapper objects in the filters, we can remove any dependency we have on the implementation of the particular portal for now. Perhaps we may even have to depend on our own bridge portlet which (like tomahawk) is derived off of the MyFaces Bridge. The things that concerns me is that never will the two run together in a portal environment if we do this. I have a requirement to allow this stuff to run in a WSRP container which is more like type 2 of your scenario. Therefore, I am flat against using an implied implementation (like taking advantage of the fact that WebSphere wraps httpServletRequest/Response objects. I *don't* mind providing an interface with various adapters (for each portal maybe) that could implement these wrapper objects as hopefully well have something similar in the spec in a year or so. That being said, while LifeRay is not of the first type you recomended, someone familiar with the system should be able to provide a wrapper object for LifeRay's PortletRequest implementation object. Scott Arash Rajaeeyan wrote: there two kind of portals some use Servlet classes as a base for Portlet and other Portlet Classes, and subclasses classes like PortletRequest from HttpServletRequest. some develop Portlet classes from scratch. lots of problems arise in second type of portlet API implementation which the Portlet classes can not be casted to Servlet classes. IBM websphere is from first kind. Liferay is second type. pluto
Re: [Jira] adding new category/component for Portlet ?
hi scot I can't find that portlet component in jira: https://issues.apache.org/jira/browse/ADFFACES can you tell me where should I look for it? On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: [Jira] adding new category/component for Portlet ?
I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: [Jira] adding new category/component for Portlet ?
hi again, I will wait for them this is a reference to what Shinsuke SUGAYA has done for myfaces I will start studying his solution till admins define those jira tasks http://wiki.apache.org/myfaces/Using_Portlets http://issues.apache.org/jira/browse/MYFACES-434 and here is link to filter: (it may not be latest version) http://portals.apache.org/bridges/multiproject/portals-bridges-portletfilter/xref/org/apache/portals/bridges/portletfilter/ On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: Tree2
Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component.What should the input be? So you are willing register also validatorson the tree?maybe that is more specialized use case instead a generic tree use case you are looking at.On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad theTree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on(editable)valueHolders to me...(like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of(edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to renderon the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and
Re: Tree2
Dear Martin I think for most people its easier to use list of values as selection model of the tree.would you please also consider adding an Ajax capability to Tree2 ?(beside server mode and client mode) regardsOn 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *,I'm reviewing the tree2 currently, and I was wondering if we couldhave a discussion about some of the concepts.First thing I'd like to discuss is what happens with selected nodes.Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be alist of values, stored at a useful place. Therefore, the tree shouldimplement the EditableValueHolder-interface, then we could do a lotmore with the values of the tree as well. The change would necessitate to move the current value attribute tosome other name - I suppose the name model would be more appropriateanyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attributeare generally quite different).Additionally, the tree is doing a lot with respect to the markup ofthe component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer thedata-model to the client (and maybe templates for each node-type), andthen render the nodes on the client dynamically.Thoughts? regards,Martin--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces -- Arash Rajaeeyan
JSF 1.2 on Java EE 5 Compatible Application Servers
there are 3 Java EE 5 Compatible Implementations:http://java.sun.com/javaee/overview/compatibility.jspSAP NetWeaver Application Server Java EE 5 Edition TmaxSoft JEUS 6Sun Java System Application Server Platform Edition 9 (Glassfish)does any body know what implementation of JSF are they using?is myfaces going to be tested on any of these implementations? RegardsArash Rajaeeyan
Re: [OT] JSF Developers Needed
Hi Zubin, please consider my resume: http://arash.rajaeeyan.googlepages.com/ArashRajaeeyanResume.html I have familar with JSF, facelets, CSS, XHTML and _javascript_. I have also read some books about user interface design.Kind regards Arash Rajaeeyan On 9/16/06, Zubin Wadia [EMAIL PROTECTED] wrote: Opportunities in the NY/NJ area - Interested Developers - please send your resume+rates to [EMAIL PROTECTED] or contact me on GTalk for details.Current positions are for Senior GUI Developers with competencies in JSF, Facelets, CSS, XHTML and _javascript_. Cheers, Zubin.-- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1294) Current logic of register extensionFilter not support portlet environment
tell me more I willing to do every thing to support portlets! On 9/12/06, Martin Marinschek (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/MYFACES-1294?page=comments#action_12433996 ]Martin Marinschek commented on MYFACES-1294:Filter -- PhaseListener and all our Portlet issues are solved. Anyone fancy doing this?regards, Martin Current logic of register extensionFilter not support portlet environment - Key: MYFACES-1294 URL: http://issues.apache.org/jira/browse/MYFACES-1294 Project: MyFaces CoreIssue Type: Bug Components: Portlet_SupportAffects Versions: 1.1.4-SNAPSHOTReporter: Serg Maslyukov (http://webmill.askmore.info)Priority: Blocker Current logic of register extensionFilter not support portlet environment fiter mappings: filter-mapping filter-nameMyFacesExtensionsFilter/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/myFacesExtensionResource/*/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping not work in portlet environment--This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see: http://www.atlassian.com/software/jira -- Arash Rajaeeyan
Re: MyFaces ECCN 5D002
don't worryI am in Iran (main part of axis of evil)we have access to all this crypto codedon't waste your time hiding them! On 9/2/06, Dennis Byrne [EMAIL PROTECTED] wrote:Apache MyFaces has bindings to the javax.crypto API.Configuration parameters, supplied by an application developer, are passed through to the javax.crypto API, employing symmetric encryption algorithms with unlimited key lengths.The following from [1] leads me to believe that Apache Myfaces release artifacts fall under ECCN 5D002 (Export Control Classification Number). the definition of ECCN 5D002, which can be summarized as: ... Software using a symmetric algorithm employing a key length in excess of 56-bitsHowever the crypto page [1] also states the following: If my project ships a binary that provides bindings to OpenSSL, but does not include its source or binaries, what notifications must be made?The only required notification for an Apache project that is specially designed to use, but doesn't include, such crypto, is just the notification for the ASF product code. I think it is reasonable to say the javax.crypto API can replace OpenSSL here?Can anyone please clarify what just the notification for the ASF product code means?To be honest, the code in question was committed more than six months ago and there have been at least three releases.Keep in mind that we don't actually release the software that performs the strong encryption; application developers have to download this *themselves* from a group like Bouncy Castle [2].Such algorithms are not even distributed with a standard JVM release. Thanks to anyone who can help me in this matter,Dennis Byrne[1] http://www.apache.org/dev/crypto.html[2] http://www.bouncycastle.org/latest_releases.html-- Arash Rajaeeyan
Re: [jira] Reopened: (MYFACES-1338) MyFaces is initialized twice in Portlet
/ the name of 'messages' - only keeping the last WARN[org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(588)] More than one managed bean w/ the name of 'form' - only keeping the last Both org.apache.myfaces.webapp.StartupServletContextListener.initMyFaces () and org.apache.myfaces.portlet.MyFacesGenericPortlet.initMyFaces() check a context attribute to see if MyFaces is initialized before invoking org.apache.myfaces.config.FacesConfigurator.configure() but both actually check and set a different attribute name. StartupServletContextListener uses: static final String FACES_INIT_DONE = StartupServletContextListener.class.getName() + .FACES_INIT_DONE; MyFacesGenericPortlet uses: protected static final String FACES_INIT_DONE = MyFacesGenericPortlet.class.getName() + .FACES_INIT_DONE; I find that if I override MyFacesGenericPortlet.initMyFaces() to do nothing, everythings works and I avoid the duplicate managed bean warnings. --This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa -For more information on JIRA, see: http://www.atlassian.com/software/jira-- Arash Rajaeeyan
Re: [jira] Commented: (TOMAHAWK-464) Make Tomahawk work in portals
I am willing to do any help to support porlets in myfaces.also can some body please, put an article on wiki telling us (newly joined developers) where to get latest sources which we should work on? (I am confused which trunk is latest sources) On 8/29/06, Michael Lipp (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-464?page=comments#action_12431161 ]Michael Lipp commented on TOMAHAWK-464: ---I strongly support eliminating ExtensionsFilter. As Michael Binette has pointed out, there is a solution for adding style sheets. There is also a solution for handling file upload in the portlet bridge (as I have shown in MYFACES-556). Delivering resources from the MyFaces/Tomahawk jars can also simply be implemented by intercepting special URLs in the Servlet (or by a phase listener if you want), so this doesn't require a filter neither. (And honestly: isn't scanning and patching the generated HTML a very clumpsy approach?) I like using MyFaces, especially I like the additional features of Tomahawk. But I think it is an error of the MyFaces team to neglect portlet support as they do. I do believe that portal based applications will become more and more important (well, I should, currently working on them ;-)). I don't know what other issues ExtensionsFilter is trying to address, but I'd be happy to help with solving them, at least conceptually.I'm afraid conceptional help is all I will be able to offer, because another flaw of the MyFaces project is maintaining the source code in the way it does. I spent three days' evenings trying to configure a source code tree that matches the 1.1.3 binary distribution for debugging a problem. The SVN tree is a total mess. E.g. what version of shared is associated with 1.1.3? The build system seems to have changed since 1.1.3. The 1.1.3-taged versions of core and tomahawk reference some file in maven (I hate maven (TM)) that does not exists. I'd really like to contribute patches but I can't reliably establish the reference. I'll now endeavour to move (at least) the adding of _javascript_ to the portlet bridge. If anybody is interested: I'm mainting my own version of such a bridge with a lot of bug fixes at http://wfmopen.cvs.sourceforge.net/wfmopen/wfmopen/src/de/danet/an/util/jsf/MyFacesAdaptedPortlet.java?view=markup. I'm positive that I'll have the _javascript_ merging in there at the end of the week. Make Tomahawk work in portals - Key: TOMAHAWK-464 URL: http://issues.apache.org/jira/browse/TOMAHAWK-464 Project: MyFaces TomahawkIssue Type: ImprovementComponents: ExtensionsFilterAffects Versions: 1.1.1, 1.1.3-SNAPSHOT, 1.1.2, 1.1.4-SNAPSHOTReporter: Danijel Jevtic The ExtensionsFilter isn't working inside Jetspeed. Though this is not a technical blocker it would be great to be able to create portlets with tomahawk components (e.g. tree2). It works fine in 1.1.0 though. Kind regards--This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see: http://www.atlassian.com/software/jira -- Arash Rajaeeyan
