Re: Playing round with 1.5 features
Hi Craig, If I take your philosophy and apply it to the managed-bean annotation, it makes only sense for the scope-annotation. The name annotation should (and will be changed) without changing the code itself. Same for navigation rules. The from-viewid as well as the to-viewid will be independent of the code, whereas the outcome very much interacts with the code. I suppose it is not quite the clear distinction you try to point out in your mail above. If you try another line of argument, you could say that navigation rules could be used in multiple action-methods, in different classes. Absolutely true. But managed beans can be used (as managed properties) in multiple other managed beans as well. And it makes no sense to configure a managed-property in the faces-config.xml, if the managed bean has been created by annotation. What I want to point out is that depending on how you see a navigation rule (as very related to the special action-method you program right now or as a general navigation rule, valid for many action methods) the usability of annotations change, but I wouldn't outright decline them. In fact, I would personally like to use annotations for some very special navigation rules, and for general navigation rules, I'd take Werner's approach of writing a semi-automatic navigation-handler. With this, I'd be pretty happy to get rid of the faces-config.xml if I don't like it. regards, Martin On 3/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/27/06, Gary VanMatre [EMAIL PROTECTED] wrote: But, I don't agree that navigation rules should be implemented with annotations. I agree with Gary on this. My general philosophy is that annotations make sense when they represent configuration information that affects how you actually code something. In JSF, the classic example is managed beans. What scope you put them in has an impact on the code you write (request scope beans do not have to care about thread safety, but session/application scope beans do, and you will likely want to ensure that session scope beans are Serializable). Having the scope setting separated from the source code risks accidental or innocent mismatches if someone changes the scope setting without thinking through the implications on the code. In EJB, you see similar sorts of issues around the transaction model that is used. Regarding navigation rules, I personally believe that action methods should report what happened (i.e. logical outcomes), not go here next. Given that philosophy, you should be able to change the navigation rules without modifying the code. Ergo, navigation rules should not be implemented in annotations (and they are not in Shale :-). Gary Craig -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
Hey Bernd, what's the state with Tobago - shouldn't we put in a drop of tobago right now? What's the state of annotations in Tobago - can we somehow merge together what we have right now? regards, Martin On 3/29/06, Bernd Bohmann [EMAIL PROTECTED] wrote: The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
Hello Martin, I think we should move the sources and the site from incubator to myfaces this week. The idea is generating the Tag classes, tld, facelet config, faces config, clay config and Design-Time Metadata from annotations with AnnotationProcessor. We are generating the tld and the facelet config for now. The other stuff is on my wish list :-) Please look at http://svn.apache.org/repos/asf/incubator/tobago/trunk/tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/annotation/ for the defined annotations. I think your proposal is more faces-config specific. But I like the idea. Are you evaluate the annotations at runtime or at source? But we should merge the stuff. Can we rename the maven dir to tool or something else. This could be the right place for the annotation stuff. Regards Bernd Martin Marinschek schrieb: Hey Bernd, what's the state with Tobago - shouldn't we put in a drop of tobago right now? What's the state of annotations in Tobago - can we somehow merge together what we have right now? regards, Martin On 3/29/06, Bernd Bohmann [EMAIL PROTECTED] wrote: The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: Playing round with 1.5 features
Yes. from sources, not at runtime. but we need some special dir for 1.5 reasons. any idea? regards, Martin On 4/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Martin, I think we should move the sources and the site from incubator to myfaces this week. The idea is generating the Tag classes, tld, facelet config, faces config, clay config and Design-Time Metadata from annotations with AnnotationProcessor. We are generating the tld and the facelet config for now. The other stuff is on my wish list :-) Please look at http://svn.apache.org/repos/asf/incubator/tobago/trunk/tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/annotation/ for the defined annotations. I think your proposal is more faces-config specific. But I like the idea. Are you evaluate the annotations at runtime or at source? But we should merge the stuff. Can we rename the maven dir to tool or something else. This could be the right place for the annotation stuff. Regards Bernd Martin Marinschek schrieb: Hey Bernd, what's the state with Tobago - shouldn't we put in a drop of tobago right now? What's the state of annotations in Tobago - can we somehow merge together what we have right now? regards, Martin On 3/29/06, Bernd Bohmann [EMAIL PROTECTED] wrote: The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
On 4/2/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,If I take your philosophy and apply it to the managed-bean annotation,it makes only sense for the scope-annotation. The name annotationshould (and will be changed) without changing the code itself. Indeed. And nothing stops you from declaring a managed bean (using the same class) in the usual way if you need this. Same for navigation rules. The from-viewid as well as theto-viewid will be independent of the code, whereas the outcome verymuch interacts with the code. I suppose it is not quite the clear distinction you try to point out in your mail above.If we agree that the from and to view ids are not appropriate in the annotations, I don't see much of a need to annotate anything related to the outcome. It is just a string that (in my opinion) should describe this is what happened, not this is where you should go next. If you try another line of argument, you could say that navigationrules could be used in multiple action-methods, in different classes. Absolutely true. But managed beans can be used (as managed properties)in multiple other managed beans as well. And it makes no sense toconfigure a managed-property in the faces-config.xml, if the managedbean has been created by annotation. Regarding managed properties, that was my original thought as well -- you can always just pre-initialize the instance variable value to whatever default you are trying to set. Then, I remembered two things: * You can also use a value binding _expression_ instead of a literal value, just like you can in a faces-config.xml file.* Using the annotation (or a managed property declaration) causes the property setter to get called, in which you might have coded side effects that you want to trigger (such as a property change event getting fired). What I want to point out is that depending on how you see a navigationrule (as very related to the special action-method you program rightnow or as a general navigation rule, valid for many action methods)the usability of annotations change, but I wouldn't outright decline them. In fact, I would personally like to use annotations for somevery special navigation rules, and for general navigation rules, I'dtake Werner's approach of writing a semi-automaticnavigation-handler. I could see a case for a completely different sort of navigation scheme, driven by its own navigation handler, that ran off its own annotations. And this wouldn't even have to conflict with the standard handler, if it delegated for cases that were not annotated. I just don't see it for the standard algorithm. With this, I'd be pretty happy to get rid of the faces-config.xml if Idon't like it. regards,MartinCraig
Re: Playing round with 1.5 features
Hi Craig, If we agree that the from and to view ids are not appropriate in the annotations, I don't see much of a need to annotate anything related to the outcome. It is just a string that (in my opinion) should describe this is what happened, not this is where you should go next. You're right - the outcome describes what happened. But it is used in the navigation rule to determine where you should go next. So if you change the code (by returning something that is different from the navigation rule outcome) the behaviour of the app will change, right? I definitely see a point to keep both the navigation rule and the action method with its outcome close together. regards, Martin
Re: Playing round with 1.5 features
On 4/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/2/06, Martin Marinschek [EMAIL PROTECTED] wrote: Same for navigation rules. The from-viewid as well as the to-viewid will be independent of the code, whereas the outcome very much interacts with the code. I suppose it is not quite the clear distinction you try to point out in your mail above. If we agree that the from and to view ids are not appropriate in the annotations, I don't see much of a need to annotate anything related to the outcome. It is just a string that (in my opinion) should describe this is what happened, not this is where you should go next. It would actually be rather useful from a tooling standpoint to be able to detect a list of possible outcomes from a method intended for an action - and very handy to narrow down the methods that are really intended as action methods, especially since in JSF 1.2 anything that takes no args and returns any type is legit. If you try another line of argument, you could say that navigation rules could be used in multiple action-methods, in different classes. Absolutely true. But managed beans can be used (as managed properties) in multiple other managed beans as well. And it makes no sense to configure a managed-property in the faces-config.xml, if the managed bean has been created by annotation. Regarding managed properties, that was my original thought as well -- you can always just pre-initialize the instance variable value to whatever default you are trying to set. Then, I remembered two things: * You can also use a value binding expression instead of a literal value, just like you can in a faces-config.xml file. Indeed, and creating ValueExpressions on the fly is a pain and hideously ugly. Also, I wouldn't be shocked if JSF started supporting re-setting properties in the future (stealing a page from Seam's bijection, for example), in which case the constructor is not sufficient. * Using the annotation (or a managed property declaration) causes the property setter to get called, in which you might have coded side effects that you want to trigger (such as a property change event getting fired). Though if you actually want the setter to be called, you could just call it from the constructor. -- Adam
Re: Playing round with 1.5 features
That would be a good idea, indeed. If it can be built separately from tobago-rest, why not? regards, Martin On 4/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Until we find the right place(name) for this stuff we could add it to Tobago? Maybe myfaces-tiger would be a nice name for the dir? Regards Bernd Martin Marinschek schrieb: Yes. from sources, not at runtime. but we need some special dir for 1.5 reasons. any idea? regards, Martin On 4/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Martin, I think we should move the sources and the site from incubator to myfaces this week. The idea is generating the Tag classes, tld, facelet config, faces config, clay config and Design-Time Metadata from annotations with AnnotationProcessor. We are generating the tld and the facelet config for now. The other stuff is on my wish list :-) Please look at http://svn.apache.org/repos/asf/incubator/tobago/trunk/tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/annotation/ for the defined annotations. I think your proposal is more faces-config specific. But I like the idea. Are you evaluate the annotations at runtime or at source? But we should merge the stuff. Can we rename the maven dir to tool or something else. This could be the right place for the annotation stuff. Regards Bernd Martin Marinschek schrieb: Hey Bernd, what's the state with Tobago - shouldn't we put in a drop of tobago right now? What's the state of annotations in Tobago - can we somehow merge together what we have right now? regards, Martin On 3/29/06, Bernd Bohmann [EMAIL PROTECTED] wrote: The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
Travis Reeder schrieb: I'm all for anything that makes component writing easier, it's pretty complex right now, so many places to make mistakes and makes it hard for a newbie to start making components. Actually there are two areas which components probably have to tackle api wise. a) The number of artefacts and glue code which are a huge burden b) The way the markup is generated. The renderers have the basic problem of having to handcode the markup via sending strings to writer objects. This gives maximum performance due to linear runtime complexity, but is a huge burden on the component developers. a split between data and markup rendering programmingwise would be saner. pushing the whole subrendering into something more readable would improve comfort. For instance if they subrendering could be pushed into something like velocity you suddenly would have the component, the bingings to the jsp or whatever subsystems and the renderer basically would be gathering data (mostly just pushing the component directly in) and then rendering it away via a sane templating markup. The main problem I see is performance, so in the end we probably are stuck with it or have to move over to client side componentization (which is the other approach, omit the api entirely as much as possible and move to a higher abstraction level like facelets do it)
Re: Playing round with 1.5 features
On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Craig, the Shale Tiger extensions are a good startin point, I read thedocs, and liked what I saw. (I also highly recommend Seam which drivesannotations to the extreme)Yep ... good stuff there too. Anyway, having had to hack components again for an extende period oftime I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had toenforce 1.3+ JDKs)What I would like to see would be a single controller and view objectwith all the taglib binding exposed via annotations instead of having to drag around an extra tag class, an extra tld and an extra faces-configentry.Components for instance are the perfect place to get rid of the xmldefintions totally (which then can be overridden with application level xml definitions if someone wants to use his own renderer)I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans. With a good use of annotations we could cut down from two xmldefinitions and 3 classes, to two classes and 1-2 annotations in the controller and view.Which means a total cut down of the code of at least 30% average and atotal cutdown of artefacts from 5 to 2.Craig
Re: Playing round with 1.5 features
Craig McClanahan schrieb: I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. Yes I was talking exactly the same issue over with Mario, definitely an area which as to be explored for the next JSP version, but for now having artefact codegens, via apt (probably a viable choice since it will be in 1.6 officially anyway) or via xdoclet2 and or velocity would be a good idea. The main point is just to have something which cuts down on the number of manual maintain artefacts. If there are codegen artefacts does not really matter. I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans. Well there are lots of areas coverable by decent codegens, facelet definitions generation comes to my mind. Thomas had something in this area already running.
Re: Playing round with 1.5 features
Craig McClanahan wrote: I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. I'm wondering if you couldn't provide a custom TagLibrary to Facelets (implements TagLibrary) that will lazily look up UIComponents from some other entity available on the ThreadLocal via the FacesContext to have them compiled into the page on first request. I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans. With a good use of annotations we could cut down from two xml definitions and 3 classes, to two classes and 1-2 annotations in the controller and view. Which means a total cut down of the code of at least 30% average and a total cutdown of artefacts from 5 to 2. Craig -- -- Sent from my FrankenBerry Wireless Handheld
Re: Playing round with 1.5 features
On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Craig, the Shale Tiger extensions are a good startin point, I read the docs, and liked what I saw. (I also highly recommend Seam which drives annotations to the extreme) Anyway, having had to hack components again for an extende period of time I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had to enforce 1.3+ JDKs) A gentle reminder: JSF was not designed by the Sun guys; there's an expert group too. ;) What I would like to see would be a single controller and view object with all the taglib binding exposed via annotations instead of having to drag around an extra tag class, an extra tld and an extra faces-config entry. With annotations, there certainly shouldn't be any need to define a component in faces-config. Nor should there be any need to write a JSP tag or add an entry to a TLD. Renderers are a bit trickier, 'cause I have run in to circumstances where I reuse the same renderer for multiple components/rendeer types, but the 99% case could be handled by annotations. Components for instance are the perfect place to get rid of the xml defintions totally (which then can be overridden with application level xml definitions if someone wants to use his own renderer) With a good use of annotations we could cut down from two xml definitions and 3 classes, to two classes and 1-2 annotations in the controller and view. Which means a total cut down of the code of at least 30% average and a total cutdown of artefacts from 5 to 2. Is the code reduction you're noting there from eliminating the JSP tag code? -- Adam Craig McClanahan schrieb: On 3/28/06, *Werner Punz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dennis Byrne schrieb: XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Actually this is getting off topic. But I see annotations as a huge improvement over central configuration in certain situations. As someone mentioned it is first of all a good place to have configurations if it has to change with your code on the fly. Secondly it cuts down severely on artefacts because annotations work on introspection, which most xml based configurations dont. So you end up with two annotations per class, within the code instead of a 20-30 line extra xml artefact. Perfect example is for instance the @WebMethode or the @Transactional annotation There are scenarios where a central configuration in xml makes perfect sense. For application singletons for instance, or db connection configuration. But this is totally off topic for now. Off topic or not :-), you can get a sense of what it would feel like to use JSF-specific annotations today, using Shale's Tiger Extensions[1]. They let you use annotations to define managed beans, register components/converters/renderers/validators, as well as get Shale's view controller functionality without having to implement the ViewController interface. Requires JSF 1.1 and JavaSE 5. The SQL Browser example app uses these, so you can see what it looks like in action. (NOTE - the app is currently bundled with MyFaces 1.1.1 that has a bug, recently fixed, that prevents the actual data in the table from being displayed -- will switch to 1.1.2 once that's released.) For application developers, not having to declare managed beans in XML can quickly spoil you. On a more general note, I believe annotations make sense when your code is designed on the assumption that the configuration variable is set a certain way. In JSF, for example, which scope the managed bean goes in can make a difference in what you do (thread safety issues, session scope beans should be Serializable, etc.). Having the setting in the class lessens the likelihood that someone will unknowingly change the configuration setting, without understanding that it might need code changes too. I don't believe annotations should be used for everything. Again, in the JSF case, I think navigation rules don't belong there -- actions should return an outcome that says this is what happened rather than this is where you should go next, and the overall flow should be managed separately (because
Re: Playing round with 1.5 features
On 3/29/06, Jacob Hookom [EMAIL PROTECTED] wrote: Craig McClanahan wrote: I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. I'm wondering if you couldn't provide a custom TagLibrary to Facelets (implements TagLibrary) that will lazily look up UIComponents from some other entity available on the ThreadLocal via the FacesContext to have them compiled into the page on first request. I was thinking of something along the lines of a Facelets annotation that defines the tag name and namespace on a component class, ditto for validators, converters, and optionally a custom handler. -- Adam
Re: Playing round with 1.5 features
On 3/29/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. Yes I was talking exactly the same issue over with Mario, definitely an area which as to be explored for the next JSP version, but for now having artefact codegens, via apt (probably a viable choice since it will be in 1.6 officially anyway) or via xdoclet2 and or velocity would be a good idea. The main point is just to have something which cuts down on the number of manual maintain artefacts. If there are codegen artefacts does not really matter. Code-gen'd artifacts *do* matter, because they contribute to the rebuild, redeploy mess that we're in now. No codegen'd artifact is better than the absence of that artifact in the first place. Not that I'm against codegen - the ADF Faces code uses it extensively - one source of metadata is used to generate the component class, faces-config, the JSP tag, the TLD, the facelets taglib, and our docs. -- Adam
Re: Playing round with 1.5 features
On 3/29/06, Werner Punz [EMAIL PROTECTED] wrote: Travis Reeder schrieb: I'm all for anything that makes component writing easier, it's pretty complex right now, so many places to make mistakes and makes it hard for a newbie to start making components. Actually there are two areas which components probably have to tackle api wise. a) The number of artefacts and glue code which are a huge burden b) The way the markup is generated. The renderers have the basic problem of having to handcode the markup via sending strings to writer objects. This gives maximum performance due to linear runtime complexity, but is a huge burden on the component developers. a split between data and markup rendering programmingwise would be saner. pushing the whole subrendering into something more readable would improve comfort. For instance if they subrendering could be pushed into something like velocity you suddenly would have the component, the bingings to the jsp or whatever subsystems and the renderer basically would be gathering data (mostly just pushing the component directly in) and then rendering it away via a sane templating markup. I've long wanted to build a declarative rendering engine for JSF. I wouldn't want to use Velocity per se or any other existing engine, because you'd lose all of the ResponseWriter goodness (which is very important for tooling) and any ability to embed other JSF components - any decent JSF component templating engine will support reusing existing JSF components, and you'd have to extend it to support some additional JSF commands anyway (e.g., render facet 'foo' here). The main problem I see is performance, so in the end we probably are stuck with it or have to move over to client side componentization (which is the other approach, omit the api entirely as much as possible and move to a higher abstraction level like facelets do it) The key thing is that you use raw Java code for all of the primitives, and get their performance as optimal as possible; once that's done, my hunch is that using a declarative engine only for some higher level aggregates and seldom-used lower level components would have relatively little impact on performance. (But as usual, this is an abstraction vs. performance issue.) -- Adam
Re: Playing round with 1.5 features
Adam Winer schrieb: On 3/29/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. Yes I was talking exactly the same issue over with Mario, definitely an area which as to be explored for the next JSP version, but for now having artefact codegens, via apt (probably a viable choice since it will be in 1.6 officially anyway) or via xdoclet2 and or velocity would be a good idea. The main point is just to have something which cuts down on the number of manual maintain artefacts. If there are codegen artefacts does not really matter. Code-gen'd artifacts *do* matter, because they contribute to the rebuild, redeploy mess that we're in now. No codegen'd artifact is better than the absence of that artifact in the first place. Not that I'm against codegen - the ADF Faces code uses it extensively - one source of metadata is used to generate the component class, faces-config, the JSP tag, the TLD, the facelets taglib, and our docs. Adam we are talking pretty much about the same area where codegens make absolute sense, as you said you applied the adf codegens to the component boilerplate code, which always more or less is the same. Now if we had a mechanism via xdoclet annotations or something else which could generate the taglib tlds, the taglib class and the facelet definitions out of a single component class, this would cut down on component development time at least 30%. To my understanding as John told me a while ago you went the opposite approach you started with a config file to generate the component skeletons, feasable, but I think having the boilerplate jsp code generated is a bigger timesaver, ideally a combination of both (skeleton generation for a kickstart, and optional boilerplate generation for development) probably would be the fastest. Anyway I am talking theoretically here anyway, I just have applied similar techniques several times, and could cut down on development time tremendously (one application had about 50% codegen coverage, pretty much the same amount could be achieved for standard components, in my opinion)
Re: Playing round with 1.5 features
Adam Winer schrieb: On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Craig, the Shale Tiger extensions are a good startin point, I read the docs, and liked what I saw. (I also highly recommend Seam which drives annotations to the extreme) Anyway, having had to hack components again for an extende period of time I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had to enforce 1.3+ JDKs) A gentle reminder: JSF was not designed by the Sun guys; there's an expert group too. ;) Sorry, for the mistake, I know about its origins and who is in the expert group ;-) Which means a total cut down of the code of at least 30% average and a total cutdown of artefacts from 5 to 2. Is the code reduction you're noting there from eliminating the JSP tag code? Mostly yes, the tld definitions and taglib binding class is pure jsp, there also could be a cut down on the faces-config parts and standard behavior like save stating that way. So it probably is 70% jsp gluecode elimination 30% jsf boilerplate code elimination. I have to run statistics but I constantly get the eery feeling that every jsf component has a huge burden of jsp binding code, xml boilerplates and some burden of jsf boilerplate code. (Probably the jsp bindings alone accounting for almost 30% of the code)
Re: Playing round with 1.5 features
Sylvain Vieujot schrieb:
I don't think we should rule out the use of annotations for navigation
rules.
Even if navigation rules are tied to the presentation layer, so are bean
names.
Actually I do not think there is a need for that.
There is a more elegant solution to the problem, than using annotations.
Implicit nav handling, that could be done without even having to touch
annotations or breaking anything.
I will give an example
usually you have a nav handler
with a from outcode ... navigate to... structure
well what would happen if we would have a basic automatic outcome to ...
mapping mechanism easily doable with a custom navhandler, which then can
be overridden by navigational entries.
What I am talking here is something along the lines:
void doAction() {
...
return mainPage
}
without any mapping would route into something like
/mainPage.jsf
and something like
void doAction() {
...
return submodule/detailPage
}
would route implicitely into
/submodule/detailPage.jsp
if you then want to override this behavior, set a custom nav entry for
mainPage and for submodule/detailPage the way it used to be.
This is way more elegant than using annotations for such a thing.
Re: Playing round with 1.5 features
Adam Winer schrieb:
Is the code reduction you're noting there from eliminating the JSP tag
code?
Mostly yes, the tld definitions and taglib binding class is pure jsp,
there also could be a cut down on the faces-config parts
and standard behavior like save stating that way.
So it probably is 70% jsp gluecode elimination 30% jsf boilerplate code
elimination.
I brought up to the WebTier EG that UIComponentTag should instead be
implemented with the DynamicAttributes contract, but this I believe was dropped
in favor of toolability.
Really, these next specs, JSP more than anything, needs to look at all of this
extra configuration *crap* as optional metadata for tooling and special cases
instead of requiring it. All of JSF's component logic within JSP tags can be
boiled down to simple rules by contract/implementation. A
UIComponentDynamicTag with the DyanmicAttributes contract would've made
dropping in new UIComponents so much easier, but now with the other default
'error when we see #{..}' in place, I don't know think even automating this
logic is even feasible.
-- Jacob
I have to run statistics but I constantly get the eery feeling that
every jsf component has a huge burden of jsp binding code, xml
boilerplates and some burden of jsf boilerplate code.
(Probably the jsp bindings alone accounting for almost 30% of the code)
Re: Playing round with 1.5 features
From: "Adam Winer" [EMAIL PROTECTED] On 3/29/06, Werner Punz <[EMAIL PROTECTED]>wrote: Travis Reeder schrieb:I'm all for anything that makes component writing easier, it's prettycomplex right now, so many places to make mistakes and makes it hard fora newbie to start making components. Actually there are two areas which components probably have to tackle api wise. a) The number of artefacts and glue code which are a huge burden b) The way the markup is generated. The renderers have the basic problem of having to handcode the markup via sending strings to writer objects. This gives maximum performance due to linear runtime complexity, but is a huge burden on the component developers. a split between data an d markup rendering programmingwise would be saner. pushing the whole subrendering into something more readable would improve comfort. For instance if they subrendering could be pushed into something like velocity you suddenly would have the component, the bingings to the jsp or whatever subsystems and the renderer basically would be gathering data (mostly just pushing the component directly in) and then rendering it away via a sane templating markup. I've long wanted to build a declarative rendering engine for JSF. I wouldn't want to use Velocity per se or any other existing engine, because you'd lose all of the ResponseWriter goodness (which is very important for tooling) and any ability to embed other JSF components - any decent JSF component templating engine will support reusing existing JSF components, and you'd have to exten d it to support some additional JSF commands anyway (e.g., "render facet 'foo' here"). I've been playing with this idea of a renderer decorator (http://issues.apache.org/bugzilla/show_bug.cgi?id=37932). This example has a specific goal and that is to inject some _javascript_ into the onclick event of a command component. The reason is to support the immediate attribute on a command when using Shale commons validator and client side _javascript_ validation. I thought that this could be made into a shale extension. Craig thought that we could insert a custom response writer that build a DOM tree from the writer hooks. But I'm not sure how we would handle the case where the component developer used a string buffer and the writer's write method versus the startElement/writeAttribute methods.I assume that these methods are the goodness that your talking about. This is the same idea as the buffer component but at the renderer level. What if velocity was used in the renderer. The velocity context was loaded with the target JSF component and faces context. The template with merged and then the product template was parsed with with an HTML/XML parser and the correct methods invoked on the response writer. This is kind of the reverse role that Facelets and Clay adds. Probably too much overhead to consider for more than a one off case. I apologize if this is offtopic. Gary The main problem I see is performance, so in the end we probably are stuck with it or have to move over to client side componentization (which is the other approach, omit the api entirely as much as possible and move to a higher abstraction level like facelets do it) The key thing is that you use raw Java code for all of the primitives, and get their performance as optimal as possible; once that's done, my hunch is that using a declarative engine only for some higher level aggregates and seldom-used lower level components would have relatively little impact on performance. (But as usual, this is an abstraction vs. performance issue.) -- Adam
Re: Playing round with 1.5 features
A custom navigation handler might be more elegant, but it's also more complex as you have to write this navigation handler, and learn a new way of configuring your application (even if it's simple). So maybe it's a good thing to have, but I would not take this as a reason not to have navigation rules as annotations.
Really I think the xdoclet jsf plugin is a good example of how to put those navigation rules in the code in a simple and useful way (even it it's not always the right solution). And for me any many other it did the job well.
The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2.
And it turns out that it works quite nicely, with the additional benefit of some kind of type safety over xdoclet. It's also much faster than the xdoclet plugin.
So my suggestion would be to start from this, and then to enhance it for those that would need more out this plugin.
On Wed, 2006-03-29 at 19:26 +0200, Werner Punz wrote:
Sylvain Vieujot schrieb:
I don't think we should rule out the use of annotations for navigation
rules.
Even if navigation rules are tied to the presentation layer, so are bean
names.
Actually I do not think there is a need for that.
There is a more elegant solution to the problem, than using annotations.
Implicit nav handling, that could be done without even having to touch
annotations or breaking anything.
I will give an example
usually you have a nav handler
with a from outcode ... navigate to... structure
well what would happen if we would have a basic automatic outcome to ...
mapping mechanism easily doable with a custom navhandler, which then can
be overridden by navigational entries.
What I am talking here is something along the lines:
void doAction() {
...
return mainPage
}
without any mapping would route into something like
/mainPage.jsf
and something like
void doAction() {
...
return submodule/detailPage
}
would route implicitely into
/submodule/detailPage.jsp
if you then want to override this behavior, set a custom nav entry for
mainPage and for submodule/detailPage the way it used to be.
This is way more elegant than using annotations for such a thing.
Re: Playing round with 1.5 features
The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd
Re: Playing round with 1.5 features
sure. It would be a good thing to revive commons for that, right? regards, Martin On 3/29/06, Bernd Bohmann [EMAIL PROTECTED] wrote: The annotations plugin we wrote and we propose to commit to a sandbox 1.5 was ment at first to replace the jsf xdoclet plugin with an annotations plugin as it's quite hard to get this xdoclet plugin work with maven 2. Tobago has already some annotations stuff. Can we share the efforts? We are using a maven-apt-plugin and an AnnotationProcessor for generating the tld's. Regards Bernd -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
I don't think we should rule out the use of annotations for navigation rules. Even if navigation rules are tied to the presentation layer, so are bean names. I also see good user cases for navigation rules defined as annotations. Here is just an example : In my projects there is a management part that always goes under the same protected URL, and that I reuse in several war files. For this, I include a jar file that contains the code, and I also include the corresponding jsp pages. I could use a corresponding xml fragment that I add in each of my projects's faces-config, but the I would then have to maintain it in each project. In such cases, using annotations, and having a plugin that automatically appends them in the faces-config file is a better solution. Also, using annotations make it possible to have a JSF project with no faces-config.xml file. So forcing such project to have an xml file just for the navigation rules would make little sense. I think the user should be able to decide by himself where to use annotations. Preventing him to use annotations for navigation rules only because we could argue it's not good programmation seems a little too inquisitorial -- and in some cases just wrong. Just one last work comparing the plugin approach to the Shale-Tiger one : One problem with annotations is that usually it's harder to debug. For example I use annotations with hibernate, and it makes debugging a little harder as it's not always that clear what configuration gets generated. With the plugin, you can both have the plugin control the configuration for you at compile time, and see the generated faces-config.xml. One good example of that is if you have two beans with a similar name. Without the plugin, in a large faces-config xml file it could be hard to spot, and with Shale-Tiger, you would get the error at deployment time. Finally, in the prototype plugin we did, you can either have everything in annotations (and no faces-config.xml), or have a faces-config.xml faces with a market that tells the plugin where to add the annotations related configuration. Sorry for this long email, and I hope we can soon agree on this sandbox 1.5 so that we can share that code/plugin with you all. Sylvain. On Mon, 2006-03-27 at 10:52 -0800, Craig McClanahan wrote: On 3/27/06, Gary VanMatre [EMAIL PROTECTED] wrote: But, I don't agree that navigation rules should be implemented with annotations. I agree with Gary on this. My general philosophy is that annotations make sense when they represent configuration information that affects how you actually code something. In JSF, the classic example is managed beans. What scope you put them in has an impact on the code you write (request scope beans do not have to care about thread safety, but session/application scope beans do, and you will likely want to ensure that session scope beans are Serializable). Having the scope setting separated from the source code risks accidental or innocent mismatches if someone changes the scope setting without thinking through the implications on the code. In EJB, you see similar sorts of issues around the transaction model that is used. Regarding navigation rules, I personally believe that action methods should report what happened (i.e. logical outcomes), not go here next. Given that philosophy, you should be able to change the navigation rules without modifying the code. Ergo, navigation rules should not be implemented in annotations (and they are not in Shale :-). Gary Craig
Re: Playing round with 1.5 features
It's all a long question with a short answer: if there are users who want it, why not add it? The XDoclet JSF plugin, as an example, has annotations for navigation rules, so obviously there is a need for it. Why not make them available, and let the users decide what they want to use? (it's all optional, don't forget that ;) I still believe it should be the users (and of course the dev's who do it) decision. And if there's someone who implements it, we should gracefully accept it. regards, Martin On 3/28/06, Sylvain Vieujot [EMAIL PROTECTED] wrote: I don't think we should rule out the use of annotations for navigation rules. Even if navigation rules are tied to the presentation layer, so are bean names. I also see good user cases for navigation rules defined as annotations. Here is just an example : In my projects there is a management part that always goes under the same protected URL, and that I reuse in several war files. For this, I include a jar file that contains the code, and I also include the corresponding jsp pages. I could use a corresponding xml fragment that I add in each of my projects's faces-config, but the I would then have to maintain it in each project. In such cases, using annotations, and having a plugin that automatically appends them in the faces-config file is a better solution. Also, using annotations make it possible to have a JSF project with no faces-config.xml file. So forcing such project to have an xml file just for the navigation rules would make little sense. I think the user should be able to decide by himself where to use annotations. Preventing him to use annotations for navigation rules only because we could argue it's not good programmation seems a little too inquisitorial -- and in some cases just wrong. Just one last work comparing the plugin approach to the Shale-Tiger one : One problem with annotations is that usually it's harder to debug. For example I use annotations with hibernate, and it makes debugging a little harder as it's not always that clear what configuration gets generated. With the plugin, you can both have the plugin control the configuration for you at compile time, and see the generated faces-config.xml. One good example of that is if you have two beans with a similar name. Without the plugin, in a large faces-config xml file it could be hard to spot, and with Shale-Tiger, you would get the error at deployment time. Finally, in the prototype plugin we did, you can either have everything in annotations (and no faces-config.xml), or have a faces-config.xml faces with a market that tells the plugin where to add the annotations related configuration. Sorry for this long email, and I hope we can soon agree on this sandbox 1.5 so that we can share that code/plugin with you all. Sylvain. On Mon, 2006-03-27 at 10:52 -0800, Craig McClanahan wrote: On 3/27/06, Gary VanMatre [EMAIL PROTECTED] wrote: But, I don't agree that navigation rules should be implemented with annotations. I agree with Gary on this. My general philosophy is that annotations make sense when they represent configuration information that affects how you actually code something. In JSF, the classic example is managed beans. What scope you put them in has an impact on the code you write (request scope beans do not have to care about thread safety, but session/application scope beans do, and you will likely want to ensure that session scope beans are Serializable). Having the scope setting separated from the source code risks accidental or innocent mismatches if someone changes the scope setting without thinking through the implications on the code. In EJB, you see similar sorts of issues around the transaction model that is used. Regarding navigation rules, I personally believe that action methods should report what happened (i.e. logical outcomes), not go here next. Given that philosophy, you should be able to change the navigation rules without modifying the code. Ergo, navigation rules should not be implemented in annotations (and they are not in Shale :-). Gary Craig -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
Dennis Byrne schrieb: XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Actually this is getting off topic. But I see annotations as a huge improvement over central configuration in certain situations. As someone mentioned it is first of all a good place to have configurations if it has to change with your code on the fly. Secondly it cuts down severely on artefacts because annotations work on introspection, which most xml based configurations dont. So you end up with two annotations per class, within the code instead of a 20-30 line extra xml artefact. Perfect example is for instance the @WebMethode or the @Transactional annotation There are scenarios where a central configuration in xml makes perfect sense. For application singletons for instance, or db connection configuration. But this is totally off topic for now.
Re: Playing round with 1.5 features
On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Dennis Byrne schrieb: XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks.After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now.This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces.Actually this is getting off topic. But I see annotations as a huge improvement over central configuration in certain situations.As someone mentioned it is first of all a good place to haveconfigurations if it has to change with your code on the fly.Secondly it cuts down severely on artefacts because annotations work on introspection, which most xml based configurations dont.So you end up with two annotations per class, within the code instead ofa 20-30 line extra xml artefact.Perfect example is for instance the @WebMethode or the @Transactional annotationThere are scenarios where a central configuration in xml makes perfectsense. For application singletons for instance, or db connectionconfiguration.But this is totally off topic for now. Off topic or not :-), you can get a sense of what it would feel like to use JSF-specific annotations today, using Shale's Tiger Extensions[1]. They let you use annotations to define managed beans, register components/converters/renderers/validators, as well as get Shale's view controller functionality without having to implement the ViewController interface. Requires JSF 1.1 and JavaSE 5.The SQL Browser example app uses these, so you can see what it looks like in action. (NOTE - the app is currently bundled with MyFaces 1.1.1 that has a bug, recently fixed, that prevents the actual data in the table from being displayed -- will switch to 1.1.2 once that's released.)For application developers, not having to declare managed beans in XML can quickly spoil you.On a more general note, I believe annotations make sense when your code is designed on the assumption that the configuration variable is set a certain way. In JSF, for example, which scope the managed bean goes in can make a difference in what you do (thread safety issues, session scope beans should be Serializable, etc.). Having the setting in the class lessens the likelihood that someone will unknowingly change the configuration setting, without understanding that it might need code changes too. I don't believe annotations should be used for everything. Again, in the JSF case, I think navigation rules don't belong there -- actions should return an outcome that says this is what happened rather than this is where you should go next, and the overall flow should be managed separately (because it can change, without needing to change the code). Craig[1] http://struts.apache.org/struts-shale/features-tiger-extensions.html
Re: Playing round with 1.5 features
Craig, the Shale Tiger extensions are a good startin point, I read the docs, and liked what I saw. (I also highly recommend Seam which drives annotations to the extreme) Anyway, having had to hack components again for an extende period of time I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had to enforce 1.3+ JDKs) What I would like to see would be a single controller and view object with all the taglib binding exposed via annotations instead of having to drag around an extra tag class, an extra tld and an extra faces-config entry. Components for instance are the perfect place to get rid of the xml defintions totally (which then can be overridden with application level xml definitions if someone wants to use his own renderer) With a good use of annotations we could cut down from two xml definitions and 3 classes, to two classes and 1-2 annotations in the controller and view. Which means a total cut down of the code of at least 30% average and a total cutdown of artefacts from 5 to 2. Craig McClanahan schrieb: On 3/28/06, *Werner Punz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dennis Byrne schrieb: XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Actually this is getting off topic. But I see annotations as a huge improvement over central configuration in certain situations. As someone mentioned it is first of all a good place to have configurations if it has to change with your code on the fly. Secondly it cuts down severely on artefacts because annotations work on introspection, which most xml based configurations dont. So you end up with two annotations per class, within the code instead of a 20-30 line extra xml artefact. Perfect example is for instance the @WebMethode or the @Transactional annotation There are scenarios where a central configuration in xml makes perfect sense. For application singletons for instance, or db connection configuration. But this is totally off topic for now. Off topic or not :-), you can get a sense of what it would feel like to use JSF-specific annotations today, using Shale's Tiger Extensions[1]. They let you use annotations to define managed beans, register components/converters/renderers/validators, as well as get Shale's view controller functionality without having to implement the ViewController interface. Requires JSF 1.1 and JavaSE 5. The SQL Browser example app uses these, so you can see what it looks like in action. (NOTE - the app is currently bundled with MyFaces 1.1.1 that has a bug, recently fixed, that prevents the actual data in the table from being displayed -- will switch to 1.1.2 once that's released.) For application developers, not having to declare managed beans in XML can quickly spoil you. On a more general note, I believe annotations make sense when your code is designed on the assumption that the configuration variable is set a certain way. In JSF, for example, which scope the managed bean goes in can make a difference in what you do (thread safety issues, session scope beans should be Serializable, etc.). Having the setting in the class lessens the likelihood that someone will unknowingly change the configuration setting, without understanding that it might need code changes too. I don't believe annotations should be used for everything. Again, in the JSF case, I think navigation rules don't belong there -- actions should return an outcome that says this is what happened rather than this is where you should go next, and the overall flow should be managed separately (because it can change, without needing to change the code). Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html
Re: Playing round with 1.5 features
Travis Reeder schrieb: I'm all for anything that makes component writing easier, it's pretty complex right now, so many places to make mistakes and makes it hard for a newbie to start making components. Yes state saving could be done annotation wise, also the taglib bindings and core faces-config definitions. Annotations used wisely on the component api would be two classes and probably 1-2 annotations per class (more if you want to explicitely lock out properties from state saving)
Re: Playing round with 1.5 features
Hi Martin,We have already discussed it directly, but I would like to stress my skepticism about the convenience to go back again to put configuration stuff in code, abandoning XML files.XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. Regards,Enrique Medina.On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *,Sylvain and me want to play around with 1.5 features a little -annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beansand navigation rules) file automatically from annotations.We considered a new subdirectory under tomahawk and maven-plugins forthis - a directory, which would not be included in the normal build, but which would have to be built separately.The directory under tomahawk might be called sandbox15.Comments - suggestions - alternatives?regards,Martin-- http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Playing round with 1.5 features
Well, yes, it's something we can discuss about - but annotations do have some merits as well. If the configuration is something that will change with the code itself, it doesn't make much sense to have it externally. In any case, it's possible to use a mixed approach without a problem. regards, Martin On 3/27/06, Enrique Medina [EMAIL PROTECTED] wrote: Hi Martin, We have already discussed it directly, but I would like to stress my skepticism about the convenience to go back again to put configuration stuff in code, abandoning XML files. XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. Regards, Enrique Medina. On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, Sylvain and me want to play around with 1.5 features a little - annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beans and navigation rules) file automatically from annotations. We considered a new subdirectory under tomahawk and maven-plugins for this - a directory, which would not be included in the normal build, but which would have to be built separately. The directory under tomahawk might be called sandbox15. Comments - suggestions - alternatives? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
Yes, Martin, that's the point. I see here another Sun crusade to the use of annotations for everything, as happened with EJBs ;-)It shouldn't be an all-or-nothing solution...On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, yes,it's something we can discuss about - but annotations do have somemerits as well.If the configuration is something that will change with the codeitself, it doesn't make much sense to have it externally. In any case, it's possible to use a mixed approach without a problem.regards,MartinOn 3/27/06, Enrique Medina [EMAIL PROTECTED] wrote: Hi Martin, We have already discussed it directly, but I would like to stress my skepticism about the convenience to go back again to put configuration stuff in code, abandoning XML files. XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. Regards, Enrique Medina. On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, Sylvain and me want to play around with 1.5 features a little - annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beans and navigation rules) file automatically from annotations. We considered a new subdirectory under tomahawk and maven-plugins for this - a directory, which would not be included in the normal build, but which would have to be built separately. The directory under tomahawk might be called sandbox15. Comments - suggestions - alternatives? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces --http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
RE: Playing round with 1.5 features
And maybe even the other way round: generate code from the config-file ;-) From: Enrique Medina [mailto:[EMAIL PROTECTED] Sent: Monday, March 27, 2006 12:04 PMTo: [EMAIL PROTECTED]Cc: MyFaces DevelopmentSubject: Re: Playing round with 1.5 features Yes, Martin, that's the point. I see here another Sun crusade to the use of annotations for everything, as happened with EJBs ;-)It shouldn't be an all-or-nothing solution... On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, yes,it's something we can discuss about - but annotations do have somemerits as well.If the configuration is something that will change with the codeitself, it doesn't make much sense to have it externally. In any case, it's possible to use a mixed approach without a problem.regards,MartinOn 3/27/06, Enrique Medina [EMAIL PROTECTED] wrote: Hi Martin, We have already discussed it directly, but I would like to stress my skepticism about the convenience to go back again to put configuration stuff in code, abandoning XML files. XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. Regards, Enrique Medina. On 3/27/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, Sylvain and me want to play around with 1.5 features a little - annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beans and navigation rules) file automatically from annotations. We considered a new subdirectory under tomahawk and maven-plugins for this - a directory, which would not be included in the normal build, but which would have to be built separately. The directory under tomahawk might be called sandbox15. Comments - suggestions - alternatives? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces --http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Playing round with 1.5 features
Great we are badly in need for something like that, there are some things, which are way better being implemented in 1.5 (for instance some interfaces which ease the component programming by exposing annotations) Martin Marinschek schrieb: Hi *, Sylvain and me want to play around with 1.5 features a little - annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beans and navigation rules) file automatically from annotations. We considered a new subdirectory under tomahawk and maven-plugins for this - a directory, which would not be included in the normal build, but which would have to be built separately. The directory under tomahawk might be called sandbox15. Comments - suggestions - alternatives? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Playing round with 1.5 features
XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Dennis Byrne
Re: Playing round with 1.5 features
I think the key point is Martin's comment:If the configuration is something that will change with the code itself, it doesn't make much sense to have it externally.It makes sense if you use them to generate your Hibernate mappings, because always it's the consequence of a change in the code (added a new field or whatever); or maybe not, e.g. you only want to tune the mapping with some type of cascade or soOn 3/27/06, Dennis Byrne [EMAIL PROTECTED] wrote:XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the pointwere we started. It seems more a response to .NET than real desirablefunctionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks.After doing my latest project w/ EJB3 annotations, I don't see much added value.But the truth is, annotations are very sexy right now.This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Dennis Byrne
Re: Playing round with 1.5 features
From: "Dennis Byrne" [EMAIL PROTECTED] XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Craig put together some annotations in Shale. http://struts.apache.org/struts-shale/features-tiger-extensions.html The managed bean registration is really nice and there is support for component, renderers, converters and validator registration. The @Value annotation isalsohandy. But, I don't agree that navigation rules should be implemented with annotations. Gary Dennis Byrne
Re: Playing round with 1.5 features
I'm all for anything that makes component writing easier, it's pretty complex right now, so many places to make mistakes and makes it hard for a newbie to start making components. Travis On 3/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think it'd be cool to create another abstract type over UIComponentBase that will automate statesaving/el vs. explicit assignment, etc via annotations. It would make component developmet a bit easier. I think the key point is Martin's comment:If the configuration is something that will change with the code itself, it doesn't make much sense to have it externally. It makes sense if you use them to generate your Hibernate mappings, because always it's the consequence of a change in the code (added a new field or whatever); or maybe not, e.g. you only want to tune the mapping with some type of cascade or soOn 3/27/06, Dennis Byrne [EMAIL PROTECTED] wrote:XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the pointwere we started. It seems more a response to .NET than real desirablefunctionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks.After doing my latest project w/ EJB3 annotations, I don't see much added value.But the truth is, annotations are very sexy right now.This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Dennis Byrne
