Re: [Graduation] Trinidad voted out of Incubator
From: Matthias Wessendorf [EMAIL PROTECTED] Dear Trinidad community, The Trinidad PPMC is pleased to let you know, that Trinidad has been voted out of the Apache Incubator. We got 12 binding +1 votes by the Apache Incubator PMC, and two more non-binding by the Incubator community (see [1]). Trinidad graduates as a subproject of the Apache MyFaces community. The next steps are allocating a SVN folder w/in the MyFaces SVN repo. The mailing lists will also be moved to myfaces. I think I can speak for all of us, that we have 13 interesting month (11,5 with sources in the SVN ;)) behind us, and we are happy to announce that leaving the Incubator has become reality. Thanks to all of you for participating in this community. Without that this never had been possible. This project has proven that Apache-style OpenSource (community-focused) is a good choice! Congratulations to the Oracle ADF Faces Team. Rock on! -Matthias [1] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
RE: Renderkit troubles
- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Saturday, April 07, 2007 12:10 PM To: adffaces-user@incubator.apache.org Subject: Re: Renderkit troubles From: Daniel Hannum I'm trying to use Trinidad for the first time (upgrading from an old ADF version) and the first problem I hit is renderkits. I keep getting Unknown RenderKit errors at deploy-time. I looked at the demo in svn and used a default renderkit of org.apache.myfaces.trinidad.core in faces-config.xml, and org.apache.myfaces.trinidad.desktop in my skin file. No matter what I do or what combination I use, it tells me that it's an unknown renderkit. Also, see the below error message Unknown RenderKit 'org.apache.myfaces.trinidad.core.desktop' I think your a package off [1]. Try 'org.apache.myfaces.trinidad.desktop'. [1] http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad- demo/src/main/webapp/WEB-INF/trinidad-skins.xml?view=markup It's putting .desktop on the end. I can't find any documentation on what's wrong or what the renderkit is supposed to be, so I'm asking the mailing list. I was looking in the XSD of the skin to try to understand how you could override specific value for any skin. There is an example in the doc of the XSD but I've not had a chance to try it. id=custom.desktop family=custom extends=simple.desktop FYI, I'm using 1.0.0-incubating which I got from http://people.apache.org/~matzew/stage_trin_core/ Thanks Gary
Re: [TRINIDAD] Setting Default submit / enter on form
From: Jochen Traunecker [EMAIL PROTECTED] Hello everybody, I'm wondering how to configure a spefic within a complex form to get activated/submitted with the user pressing ? Or is there a better way to submit a form by pressing like configuring a ? The tr:form component has a defaultCommand attribute that you can chain to a command button. I've used this under the ADF components and it works very well. Under the ADF components, the name of the command button ends up being displayed through some script so the id of the commandButton needs to be something that can be displayed in the text of the button for a couple of seconds. I'm not sure it the Trinidad from version works the same. Thx, Jochen Gary ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Dynamic Navigation
From: Justin Mckay [EMAIL PROTECTED] Hi all, I am in the process of moving our project from Oracle's ADF to Trinidad. One thing we are having a problem with is dynamic navigation from a ValueChangeEvent(selectOneChoice). This did work with Oracle's ADF but is not working now. It seems like the page is created(backing beans are called and the page seems to be generated), we are just not actually moving to that page. One thing to note is this code does work from an ActionEvent(Button or Link). Any ideas or other strategies to consider? String path = /misc/finder.xhtml; FacesContext fContext = FacesContext.getCurrentInstance(); ViewHandler vh = fContext.getApplication().getViewHandler(); UIViewRoot uroot = vh.createView(fContext, path); fContext.setViewRoot(uroot); I've seen something that sounds similar but I'm not sure if it's your problem. I had client side state saving turned on. This meant that the saved state was in the request from the previous submit. I was using an external context dispatch instead of swapping the view root. The dispatch keeps the request scope (forward) the same as swapping the view root. The Trinidad state manager was restoring the view from the state captured from the previous submit. It was not comparing the viewid of the restored view to the current view. I submitted a patch for this one but I've since lost track of it's status. Something else you might try is invoking the renderResponse after swapping the view root. FacesContext fContext = FacesContext.getCurrentInstance(); FContext.responseComplete(); ViewHandler vh = fContext.getApplication().getViewHandler(); UIViewRoot uroot = vh.createView(fContext, path); fContext.setViewRoot(uroot); fContext.renderResponse(); Justin McKay Gary Java Developer FAMIS Software, Inc. [EMAIL PROTECTED] (949) 553-6564 telephone (949) 553-6559 fax http://www.famis.com
Re: Skinning Tags
From: Jeanne Waldman [EMAIL PROTECTED] Simon/Gary, We can inherit from any skin in Trinidad already. You use the element in the trinidad-skins.xml file and the value that goes in there is the skin-id of the skin you want to extend.. I'll add a demo if there isn't one already. I haven't seen one but it might be in the demo app someplace. Regardless, it seems like a big improvement that should be evangelized. Especially to the ADF component users that are looking for good reason to take Trinidad seriously. Thanks, Jeanne Gary Simon Lessard wrote: Hello Gary We plan to add inheritance from any skin, not just from simple in the future, so you'll be able to override just what you want. Regards, ~ Simon On 3/30/07, Matt Cooper wrote: It would be very cool to have a page or set of pages in the demo project that served as a skin generator where the user could create a skin using a GUI and not have to know anything about CSS. If anyone is looking for a project, this would be a very cool one to donate. ;-) On 3/30/07, Gary VanMatre wrote: From: Jeanne Waldman You should be able to create an html file from the skin-selectors.xml file by running 'mvn site'. - Jeanne I really like this global skinning concept but it would be nice if there was a way to just override a few things in a skin. From what I understand, it's a all of nothing type of approach (speaking from the ADF 10.1.3.2side) and only an option for the simple skin. I'd like to be able to pick an existing skin but only override a couple of things. This would be very handy for the CSS challenged. Is this possible in Trinidad? Gary Simon Lessard wrote: There's two places: For the full list, if you downloaded the source files, in /trinidad/src/site/xdoc/skin-selectors.xml For the old list (from ADF Faces): http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/j sf/doc/skin-selectors.html Regards, ~ Simon On 3/30/07, Chris Hane wrote: I've started to edit a custom skin for Trinidad. I thought I saw somewhere a tag list for each component. And of course I can't find it now that I'm looking for it. Could someone point me to the page that lists the elements for each component that can be skinned? Thanks, Chris
Re: Skinning Tags
From: Jeanne Waldman [EMAIL PROTECTED] You should be able to create an html file from the skin-selectors.xml file by running 'mvn site'. - Jeanne I really like this global skinning concept but it would be nice if there was a way to just override a few things in a skin. From what I understand, it's a all of nothing type of approach (speaking from the ADF 10.1.3.2 side) and only an option for the simple skin. I'd like to be able to pick an existing skin but only override a couple of things. This would be very handy for the CSS challenged. Is this possible in Trinidad? Gary Simon Lessard wrote: There's two places: For the full list, if you downloaded the source files, in /trinidad/src/site/xdoc/skin-selectors.xml For the old list (from ADF Faces): http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/j sf/doc/skin-selectors.html Regards, ~ Simon On 3/30/07, Chris Hane wrote: I've started to edit a custom skin for Trinidad. I thought I saw somewhere a tag list for each component. And of course I can't find it now that I'm looking for it. Could someone point me to the page that lists the elements for each component that can be skinned? Thanks, Chris
Re: Skinning Tags
From: Matt Cooper [EMAIL PROTECTED] It would be very cool to have a page or set of pages in the demo project that served as a skin generator where the user could create a skin using a GUI and not have to know anything about CSS. If anyone is looking for a project, this would be a very cool one to donate. ;-) That would be freaking awesome. Matt, your the guy with the CSS knowledge :-) You guys need something like that for JDeveloper. Don't get me wrong, the JSF/JSP design support it top-notch but that would attract OSers as well as enterprise developers. Gary On 3/30/07, Gary VanMatre wrote: From: Jeanne Waldman You should be able to create an html file from the skin-selectors.xml file by running 'mvn site'. - Jeanne I really like this global skinning concept but it would be nice if there was a way to just override a few things in a skin. From what I understand, it's a all of nothing type of approach (speaking from the ADF 10.1.3.2side) and only an option for the simple skin. I'd like to be able to pick an existing skin but only override a couple of things. This would be very handy for the CSS challenged. Is this possible in Trinidad? Gary Simon Lessard wrote: There's two places: For the full list, if you downloaded the source files, in /trinidad/src/site/xdoc/skin-selectors.xml For the old list (from ADF Faces): http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/j sf/doc/skin-selectors.html Regards, ~ Simon On 3/30/07, Chris Hane wrote: I've started to edit a custom skin for Trinidad. I thought I saw somewhere a tag list for each component. And of course I can't find it now that I'm looking for it. Could someone point me to the page that lists the elements for each component that can be skinned? Thanks, Chris
Re: Skinning Tags
From: Simon Lessard [EMAIL PROTECTED] Hello Gary We plan to add inheritance from any skin, not just from simple in the future, so you'll be able to override just what you want. That would be really helpfully. In my experience, one of the benefits of the global skin is that as a developer, you don't have to focus on the look-and-feel. However, when the user insists that a graphic is not intuitive, even after adding three paragraphs to the short description and a tip panel, it would nice to not have to make the huge leap into creating a skin from scratch. Gary Regards, ~ Simon On 3/30/07, Matt Cooper wrote: It would be very cool to have a page or set of pages in the demo project that served as a skin generator where the user could create a skin using a GUI and not have to know anything about CSS. If anyone is looking for a project, this would be a very cool one to donate. ;-) On 3/30/07, Gary VanMatre wrote: From: Jeanne Waldman You should be able to create an html file from the skin-selectors.xml file by running 'mvn site'. - Jeanne I really like this global skinning concept but it would be nice if there was a way to just override a few things in a skin. From what I understand, it's a all of nothing type of approach (speaking from the ADF 10.1.3.2side) and only an option for the simple skin. I'd like to be able to pick an existing skin but only override a couple of things. This would be very handy for the CSS challenged. Is this possible in Trinidad? Gary Simon Lessard wrote: There's two places: For the full list, if you downloaded the source files, in /trinidad/src/site/xdoc/skin-selectors.xml For the old list (from ADF Faces): http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/j sf/doc/skin-selectors.html Regards, ~ Simon On 3/30/07, Chris Hane wrote: I've started to edit a custom skin for Trinidad. I thought I saw somewhere a tag list for each component. And of course I can't find it now that I'm looking for it. Could someone point me to the page that lists the elements for each component that can be skinned? Thanks, Chris
Re: How to set focus to an inputText
Everyone,
Does anybody know how to set initial focus to a tr:inputText when a
jsf page loaded?
I'm not using tr:document tag - so I cannot use initialFocusId
Sample code:
ui:composition
...
...
...
tr:panelGroupLayout layout=vertical
tr:inputText id=addressLine1
label=#{addressProps.values.addressLine1}
tr:inputText id=addressLine2
label=#{addressProps.values.addressLine2}
tr:inputText id=addressLine3
label=#{addressProps.values.addressLine3}
...
...
...
/ui:composition
How to set the focus to addressLine1 inputText?
Many thanks in advance
You might try using the trh:body component. It also has a initialFocusId
attribute.
--Krishna
Gary
Re: Components reinjected losing disabled state
From: Daniel Hannum [EMAIL PROTECTED] This may be a basic JSF question... I'm not sure. I have a component on a page that is bound to a backing bean member. During page logic, I use setDisabled(true) to disable the component under some conditions. Now, after the form is submitted, JSF seems to reinject new component objects into my backing bean. So, the next time the page is displayed, loses the disabled state. I didn't know it would do this. I guess I thought I would get to keep my component instances and not have new ones given to me on each request. As far as a solution goes, I guess I could put logic in the getter (getMyComponent()) for figuring out if we should be disabled or not. That way it would always be done, but it seems inefficient to do it every time. Does that seem like the best solution? I know putting the logic in the markup itself would also work, though I think I need to do more than EL can do (I need to check if a radio button has a particular value). Thoughts? You might check to make sure that your backing bean is in session or pageFlowScope scope. Something else to look at is the use of action versus actionListener binding to command components. If you use an action binding returning an outcome that matches a navigation rule in the faces-config.xml, the component tree will be recreated with all new component instances. If you use the actionListener binding, the component tree will be preserved. Thanks. Gary
RE: Components reinjected losing disabled state
From: Daniel Hannum [EMAIL PROTECTED]
It's not request scoped, so I could do
public MyComponent getMyComponent() {
myComponent.setDisabled(radioButtonValue == 1);
return myComponent;
}
But that's ugly
Best way to keep it from reseting is do it in the markup
yourComponent disabled=#{radioButtonValue == 1}/
But that's putting a magic number in the UI. Not good.
actionListeners were recommended because they don't reset the component
tree, but I don't like it because I really do need to do business logic,
it just happens to bring you back to the same page. Actions seem like
the right thing, but they reset the tree, and there's no good place to
put the components back the way they're supposed to be.
Still seems to be no good solution. Is there something I'm not seeing?
You could create a constants managed bean that you placed in application
scope to hold your magic numbers.
yourComponent disabled=#{radioButtonValue eq constants.radioButtonValue}/
-Original Message-
From: noah [mailto:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 12:29 PM
To: adffaces-user@incubator.apache.org
Subject: Re: Components reinjected losing disabled state
On 3/23/07, Daniel Hannum wrote:
This may be a basic JSF question... I'm not sure.
I have a component on a page that is bound to a backing bean member.
During page logic, I use setDisabled(true) to disable the component
under some conditions. Now, after the form is submitted, JSF seems to
reinject new component objects into my backing bean. So, the next time
the page is displayed, loses the disabled state. I didn't know it
would
do this. I guess I thought I would get to keep my component instances
and not have new ones given to me on each request.
As far as a solution goes, I guess I could put logic in the getter
(getMyComponent()) for figuring out if we should be disabled or not.
That way it would always be done, but it seems inefficient to do it
every time.
If checking disabled is an expensive operation, then cache the result,
e.g.
public boolean isDisabled() {
if(this.disabled == null) {
this.disabled = expensiveCalculation();
}
return disabled;
}
But you'll need some other logic to determine if disabled needs to be
reevaluated, unless your bean is request scoped.
Does that seem like the best solution? I know putting the logic in the
markup itself would also work, though I think I need to do more than
EL
can do (I need to check if a radio button has a particular value).
Then probably you should be checking if the property the radio button
is bound to has a particular value, rather than checking the actual
radio button. e.g.
Re: Templating with trinidad once more
From: Matthias Wessendorf [EMAIL PROTECTED] Hello Kuno, I'd like use a basic template feature with trinidad and like to inform me about the actual situation of this issue. I've found a statement of Matthias Wessendorf, he states that one should use facelets. However, facelets isn't a standard. Furthermore, I couldn't find any examples well, not a standard in the meaning of JCP, but build on-top of JSF and very close to JSF, compared to other stuff like Tiles (the creator of Facelets is part of the JSF 1.2 EG). An example of using Trinidad + Facelets is here: http://code.google.com/p/facesgoodies/ (and some other stuff) with trinidad and my migrated JSF examples didn't work (illegal component hierarchy detected, expected UIXCommand but found another type of component instead.). I reckon, it might be a problem with nested forms, however, this would be another entry... Meaning form ... form ... /form ... /form ? ... ? This is invalid in HTML and using Apache MyFaces as your JSF runtine, you will get a warning, when nesting the corresponding components (no idea, what the RI tells you). In my opinion, this is more than one reason do not move to facelets. Are That's up to you. There is also Clay, also close to JSF, since was developed having JSF in mind. Gary, might know how good Clay is working w/ Trinidad. In my experience, Clay and Trinidad work well together. There is a sample testbed project in the Shale sandbox that shows this integration [1]. I hoped to create a shale maven archetype out of this effort similar to the shale-archetype-blank [2] but haven't made time yet. However, I'm not a member of the JSF EG nor do I work for the Oracle ADF faces runtime group. [1] http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/ [2] http://svn.apache.org/viewvc/shale/maven/trunk/archetypes/shale-archetype-blank/ HTH, Matthias Gary there any other options? Did somebody get Tiles working with trinidad? Is there any roadmap for this issue? Many thanks Kuno -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: RE : AW: templating mecanism ?
From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much But I really need to use JSP for rendering (not facelets) - my IDE doesn't support JSF design with facelets syntax. Another less popular alternative would be Shale Clay [1]. It can be used with JSP and has a number of options. [1] http://shale.apache.org/shale-clay/index.html Do you know a templating solution for JSP engine ? --- Döring Markus a écrit : Gary Hello, Trinidad comes with a buildin Facelets library and Facelets has a very powerfull templating mechanism. Just have a look at it and test if it's what you need. Greetings Markus -Ursprüngliche Nachricht- Von: Adrian Gonzalez [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 1. Februar 2007 14:32 An: adffaces-user@incubator.apache.org Betreff: templating mecanism ? Hello, I would like to know if there's a templating mecanism provided by trinidad (or usable with trinidad) and usable for JSP rendering ? I've tried Shale Tiles extension with ADF Faces, and it doesn't work, so I would like to know if there's a substitute. Moreover I don't want to use sitemesh engine for composition (cause of the parsing performance impact). The region tags enable composition but not templating I think. Thanks __ _ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
ADFFaces API versus Trinidad
In Trinidad, you can add script using the following code snippet:
ExtendedRenderKitService service = (ExtendedRenderKitService) Service
.getRenderKitService(facesContext,
ExtendedRenderKitService.class);
service.addScript(facesContext, alert('Hi'););
How would you do this with the Oracle ADF API?
Thanks,
Gary
Re: ADFFaces API versus Trinidad
From: Matthias Wessendorf [EMAIL PROTECTED]
Hi Gary,
here is a blog entry of me to that:
http://www.jroller.com/page/mwessendorf?entry=using_extendedrenderkitservice
I also saw it in the Trinidad archetype example app you put together (very
nice).
The code is only in the donated code, not the downloadable ADF FACES
Oh, I see, so the ADF faces bundled with jdevelper won't have this API
extension available in Trinidad.
Will Oracle continue to maintain two component libraries or will Trinidad be
the offering in the future? If you can't answer that one, I understand
However, it would be a good argument to convince a client to use Trinidad
instead :--)
Thx,
Matthias
Gary
On 2/1/07, Gary VanMatre wrote:
In Trinidad, you can add script using the following code snippet:
ExtendedRenderKitService service = (ExtendedRenderKitService) Service
.getRenderKitService(facesContext,
ExtendedRenderKitService.class);
service.addScript(facesContext, alert('Hi'););
How would you do this with the Oracle ADF API?
Thanks,
Gary
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Re : RE : AW: templating mecanism ?
From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much everyone for your help on this topic. I'll have a look at Facelets (and perhaps Clay, but latter since it's less used). I really have the impression that everyone (or quite everyone) using JSF is using Facelets, so Just another question (last, I swear it !) : Do you, JSF app developpers (and not component developers), use an IDE with drag and drop capabilities (RAD kind of development) for facelets or no ? Which one ? I'm just using IBM RAD 6, and it's really difficult (ibm proprietary components, JSF 1.0, JSP...) You might also ask this one on the shale users list. Ryan Wynn works with Websphere (IBM Consulting) hangs out there [1]. Although, a Shale Clay enthusiast - something like 20 porlets using Shale Clay. [1] https://issues.apache.org/struts/browse/SHALE-402 Gary - Message d'origine De : Gary VanMatre À : adffaces-user@incubator.apache.org Envoyé le : Jeudi, 1 Février 2007, 16h49mn 50s Objet : Re: RE : AW: templating mecanism ? From: Adrian Gonzalez Thank you very much But I really need to use JSP for rendering (not facelets) - my IDE doesn't support JSF design with facelets syntax. Another less popular alternative would be Shale Clay [1]. It can be used with JSP and has a number of options. [1] http://shale.apache.org/shale-clay/index.html Do you know a templating solution for JSP engine ? --- Döring Markus a écrit : Gary Hello, Trinidad comes with a buildin Facelets library and Facelets has a very powerfull templating mechanism. Just have a look at it and test if it's what you need. Greetings Markus -Ursprüngliche Nachricht- Von: Adrian Gonzalez [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 1. Februar 2007 14:32 An: adffaces-user@incubator.apache.org Betreff: templating mecanism ? Hello, I would like to know if there's a templating mecanism provided by trinidad (or usable with trinidad) and usable for JSP rendering ? I've tried Shale Tiles extension with ADF Faces, and it doesn't work, so I would like to know if there's a substitute. Moreover I don't want to use sitemesh engine for composition (cause of the parsing performance impact). The region tags enable composition but not templating I think. Thanks __ _ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: AW: Shale and dialog framework
From: Meyer, Stefan [EMAIL PROTECTED] I take it back. I have no idea why it doen't work as I expected it to. Ya I agree, that's some voodoo going on there :--) Kind of like reading the CliffsNotes to find all the hidden meaning. -Ursprüngliche Nachricht- Von: Adam Winer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 16:19 An: adffaces-user@incubator.apache.org Betreff: Re: Shale and dialog framework Not exactly the behavior's a bit more complicated than that. There's not two simultaneous calls, but there are calls to the original page that may not be obvious. Here's how it goes. in all the gory detail: In browser: User clicks on a commandButton Request 1: Postback handling: - ActionEvent is broadcast, and NavigationHandlerImpl notes it begins with dialog: - Instead of navigating to that UIViewRoot, a LaunchEvent is queued with the target UIViewRoot - UIXCommand component receives the launch event, and asks the RequestContext to launch a dialog. - The RequestContext asks the RenderKit if it supports launching dialogs, and if so, tells it to launch a dialog on this request. Rendering: - A bit of Javascript is rendered that will launch a popup. (Not during onload, per se, just inline). The JS points not directly at the target view ID, but at an intermediate frameset that will in turn launch the target view ID (but this implementation strategy is encapsulated inside of the RK) Back on the browser, a new window pops up with the correct URL. Request 2: Rendering only: - An URL comes in requesting the frameset rendering - It's intercepted by our ViewHandler, which recognizes that the viewId is that of a registered InternalView - another public extensible API in Trinidad - and therefore is handled without going to any JSPs Request 3: Rendering only: - The dialog's viewId finally loads User clicks a commandButton (for example, could be anything) in a page Request N-1: Postback: - Action listener calls RequestContext.returnFromDialog() - RenderKit is again involved Rendering: - Javascript is rendered to return from the dialog, by submitting the original window Back on the browser, the original window receives a form submission while the popup window closes. Request N: Postback: - The original commandButton's Renderer detects a ReturnEvent, and queues it - A returnListener does whatever it wants to And that's all there is to it. ;) Well, actually, it's more complicated than that, because this rendering generally all happens with partial-page rendering, so nothing flashes on the original page as this happens, and new pageFlowScopes are being created, populated, and destroyed. I'd love to see this hooked up to a popup system (probably by using a DHTML popup containing an IFRAME pointing at the target URL). That could happen without any public API changes or modification of user's JSP or Facelets pages. -- Adam On 1/30/07, Meyer, Stefan wrote: The issue is pretty obvious. The Dialog framework launches a popup in the onload js event, if the outcome / action starts with the dialog: keyword and the action was launched by a commandButton/commandLink with the useWindow attribute set to true. Basically the dialog framework renders two views in two separate windows at once. The outcome specifies the view to display in the popup window while the orignial view is left unchanged. Therefore shale calls the lifecycle methods in both requests on the same viewController. That Viewcontroller should only handle the popup view though. Stefan -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Craig McClanahan Gesendet: Montag, 29. Januar 2007 22:44 An: adffaces-user@incubator.apache.org Betreff: Re: Shale and dialog framework On 1/29/07, Laurie Harper wrote: On 29-Jan-07, at 2:21 PM, Craig McClanahan wrote: On 1/29/07, Meyer, Stefan wrote: The Viewcontroller does not work well with the dialog framework, because the lifecycle methods are called on the popup view bean for the parent and child request and not at all for the launching view. Fixing this would maybe mean, that the action outcome cannot define the view to present in the popup. Stefan, I am not sure I quite get what you mean here. My assumption, when you are using a popup, is that you'll be using client side JavaScript to actually create the popup. Here's a snippet of code from our shale-test-dialog-basic and shale-test-dialog-scxml test applications that does it: Note that this does *not* send back a request for the calling view (the page in which the JavaScript above was embedded), so there is no reason to invoke any callback methods for it. This
problem using jdev maven plugin
I was trying for the first time to use the maven plugin to generate a JDeveloper project. Has anyone seen this error? $ mvn jdev:jdev [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'jdev'. [INFO] - --- [INFO] Building A custom project using myfaces [INFO]task-segment: [jdev:jdev] [INFO] - --- [INFO] Preparing jdev:jdev [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [jdev:jdev] [INFO] Generating JDeveloper 10.1.3.0.4 Project ccatApp [INFO] - [ERROR] BUILD ERROR [INFO] - [INFO] Unable to read resource: 10.1.3.0.4/project.xml [INFO] - [INFO] For more information, run Maven with the -e switch [INFO] - [INFO] Total time: 1 second [INFO] Finished at: Wed Jan 31 12:05:12 MST 2007 [INFO] Final Memory: 3M/6M [INFO] - Gary
problem using jdev maven plugin
I was trying for the first time to use the maven plugin to generate a JDeveloper project. Has anyone seen this error? Ok, this plugin is for maven 1. Anyone know of a maven 2 plugin? Or, any tips working with JDeveloper 10.1.3? Gary
Re: problem using jdev maven plugin
From: Adam Winer [EMAIL PROTECTED] I swear, it's a Maven 2 plugin. All of the Trinidad plugins are... All-righty then, how do you build the 10.1.3.0.4/project.xml file that it's trying to read? -- Adam Gary On 1/31/07, Gary VanMatre wrote: I was trying for the first time to use the maven plugin to generate a JDeveloper project. Has anyone seen this error? Ok, this plugin is for maven 1. Anyone know of a maven 2 plugin? Or, any tips working with JDeveloper 10.1.3? Gary
Re: Shale and dialog framework
From: Craig McClanahan [EMAIL PROTECTED] On 1/29/07, Meyer, Stefan wrote: The Viewcontroller does not work well with the dialog framework, because the lifecycle methods are called on the popup view bean for the parent and child request and not at all for the launching view. Fixing this would maybe mean, that the action outcome cannot define the view to present in the popup. Stefan, I am not sure I quite get what you mean here. My assumption, when you are using a popup, is that you'll be using client side JavaScript to actually create the popup. Here's a snippet of code from our shale-test-dialog-basic and shale-test-dialog-scxml test applications that does it: I was looking at the Trinidad's Dialog the other day. The Trinidad dialog also uses Javascript to launch a new browser window [1] but the hook is seamless if you are using their widgets (Trinidad) which have their own rendering strategy [2]. This is a huge advantage that a full component library might offer since they offer components that encapsulate this functionality. Another example might be to compare Shale's commons validator's client side script support versus Trinidad's. In Trinidad, each server side validator has a corresponding client javascript validator. The same is true for converters. Shale's client side validator support is patterned from Struts. The client side validation scirpt is rendered from a component that you add to the bottom of the page that inspects all the validators and adds the script. I like Trinidad's approach. Each JSF component (widget, validator, converter, listener) should act on it's own behalf. But, the problem is that only components participate in rendering markup. Trinidad's approach is very elegant but cohesive. Shale's approach as been less component library centric and more API centric. Maybe what we need is for the JSF API to standardize on a script delivery channel, dialog mechanism, and a pluggable rendering extensions for validators and converters? Gary [1] https://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/DialogRequest.java?view=markup [2] https://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderKit.java?view=markup Note that this does *not* send back a request for the calling view (the page in which the JavaScript above was embedded), so there is no reason to invoke any callback methods for it. This request will open a new window, and the callbacks for the menu.faces page will be called as expected. What part of this behavior is not working for you? Craig
Re: Master detail drop down lists
From: Duong BaTien [EMAIL PROTECTED] Gary: Thanks the references. Yes, i am aware of these and still learning Trinidad. Yeah, me too. It has been fun. On Mon, 2007-01-22 at 23:35 +, Gary VanMatre wrote: From: Duong BaTien Hi: I am looking for the best suggested implementations of master/detail drop down lists (countries - regions) in 1 or 2 month time frame that may be re-used under jsf 1.2. Any suggestion? Could some body give me links to email archives of myfaces and trinidad so i can do some search. Trinidad framework gives you a ton of ammunition for a master/detail interface (maybe too many). You can find some good documentation (with pictures) of the ADF components [1] on the oracle site and then reference the api-changes [2]. The tr:table [3], tr:tree [4] and tr:tableTree components have some events for state selection that helps out with master/detail. All the Trinidad components support PPR making the dependent drop trivial. [1] http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/j sf/doc/tagdoc/core/imageIndex.html [2] http://incubator.apache.org/adffaces/api-changes.html [3] http://incubator.apache.org/adffaces/devguide/table.html [4] http://incubator.apache.org/adffaces/devguide/tree.html Thanks. Gary
Re: unsubscribe
From: Clinton Davidson [EMAIL PROTECTED] See http://incubator.apache.org/adffaces/trinidad-build/mail-lists.html ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: tr:inputText disabled=true pageFlowScope
From: Mark Dopheide [EMAIL PROTECTED]
Adam,
Well, clearly I'm the one confused but I can't see my way beyond it.
My backing bean does this:
RequestContext requestContext = RequestContext.getCurrentInstance();
requestContext.getPageFlowScope().put(registration, registration);
// ex: registration.candidateId = 111;
My view has this readOnly tag:
label=#{text['registration.candidateId']} :
value=#{pageFlowScope.registration.candidateId}
readOnly=true
/
When the form is submitted, I retrieve it in the postback:
Registration registration = (Registration)
app.getVariableResolver().resolveVariable(context, registration);
Oh, I think the problem is that you are not finding the registration bean in
pageFlowScope. The variable resolver doesn't search this scope. You will need
to use the RequestContext. Or, you could create a value binding expression.
ValueBinding vb = app.createValueBinding(#{pageFlowScope.registration});
Registration registration = (Registration) vb.getValue(context);
However, the registration.candidateId = 0, the attributes that are NOT
readOnly DO have their attributes preserved correctly.
It seems simple enough but apparently something is erroneous, though I have
no clue as to what it is. I assume I don't need managed-property for this in
my faces-config.xml file.
Thanks again for any insights...
Mark
Gary
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 20, 2007 3:24 PM
To: adffaces-user@incubator.apache.org
Subject: Re: tr:inputText disabled=true pageFlowScope
Mark,
I'm confused about the problem. Since you've disabled the field, JSF won't
write the value back to the EL target. OTOH, since that value was
originally retrieved from pageFlowScope, it'll still be there on postback.
So it doesn't seem that you should be any worse-off on the postback. What
am I missing?
-- Adam
On 1/20/07, Adam Winer wrote:
On 1/19/07, Mark Dopheide wrote:
Gary,
Yes, essentially you have captured what I am trying to do. The crux
of the problem is where you say:
If your user object already has a value in the candidateId
property, a
disabled input component won't
update the property. Your candidateId in the user object should
keep the
prepopulated value and be
ready to save.
What's happening is that when my User object is retrieved from the
edit detail view with this:
Registration registration = (Registration)
getRequest().getAttribute(registration);
the prepopulated but disabled (or readOnly) attributes that are not
intended to be edited do not have the expected values (i.e. instead
of for candidateId the backing bean gets 0). Now I surmise
that this is because validation is not performed on these readOnly
attributes, but I would really like to find an elegant way of
maintaining these values in the object that is returned from the
view. Again, if I add
value=#pageFlowScope.registration.candidateId).../ then these
attributes are maintained but then my keyboard gets that cramp again
;)
If only half of the attributes in my object are intended to be
edited and that object is retrieved from the view then what? Am I
forced to write code to transfer the missing or modified
attributes back into my hibernate managed object? Having hidden inputs
in my HTML just seems so wrong
Mark
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Friday, January 19, 2007 11:29 PM
To: adffaces-user@incubator.apache.org
Subject: Re: tr:inputText disabled=true pageFlowScope
From: Mark Dopheide
Guidance required on this issue...
Realizing that when using tr:inputText and pageFlowScope (or
saveState) the readOnly (or disabled) attributes do not get
submitted to the backing bean as to the model, then...
What is recommended practice when these disabled values are to
be persisted? For example, if I am using pageFlowScope and in my
backing bean has something like:
User user = (User)
app.getVariableResolver().resolveVariable(context,
user);
And my web pages contains:
label=#{text['registration.candidateId']} :
value=#{pageFlowScope.registration.candidateId}
disabled=true
contentStyle=margin: 1em 0 0 0;color: blue
required=true/
then this regCode attribute that is declared readOnly does not
appear in my User model in the backing bean. This is kind of a
pain in the keyboard
;^)
pain in the keyboard... Ha! Now that's funny!
What is recommended practice in these situations? Certainly on
the disabled attributes is possible but this seems to lack the
elegance that I
would expect.
I mean when using hibernate, etc
Re: Partial Triggering in tr:table
From: Anshuman Abhishek Roy [EMAIL PROTECTED]
Hi,
I am unable to do a PPR in my component.
I have a table with various columns of input text in it. The requirement is
to
display the total on the last column. Although in my backing bean everything
works fine and total is updated but I am not able to update in the page
itself.
I have used autosubmit=true in my and also I have used partial
triggers. But total is not getting updated.
for reference I am putting the code below:
tr:table id=XYZComponentTable var=abc
value=#{XYZComponentBackingBean.getList}
binding=#{XYZComponentBackingBean.table} rows=10
tr:column align=right
f:facet name=header
tr:outputText value=* Date /
/f:facet
tr:inputDate value=#{abc.Date} /
f:facet name=footer
tr:outputText value=Total
styleClass=refAreaTextBold/tr:outputText
/f:facet
/tr:column
tr:column
f:facet name=header
tr:outputText value=* Amount($) /
/f:facet
tr:inputText id=amount
value=#{abc.Amount}
simple=true
columns=12
immediate=true
autoSubmit=true
valueChangeListener=#{abc.computeAmount}
required=true/
f:facet name=footer
tr:outputText value=#{XYZComponentBackingBean.netTotal}
readOnly=true
partialTriggers=amount/
/f:facet
/tr:column
/tr:table
Am I missing something??
If you don't already, I would try adding the table under a tr:form and
tr:panelPartialRoot.
tr:form id=form
tr:panelPartialRoot id=ppr
tr:table ...
/tr:panelPartialRoot
/tr:form
regards,
Anshuman
Gary
Disclaimer
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom it is addressed. If
you
have received this communication in error, please immediately notify the
[EMAIL PROTECTED] and destroy the original message. The recipient should
check this email and any attachments for the presence of viruses. Ness has
taken every reasonable precaution to minimize this risk, and accepts no
liability for any damage caused by any virus transmitted in this email. Ness
reserves the rights to monitor and review the content of all messages sent to
or
from this E-mail address, and store them on the Ness E-mail system.
Re: tr:inputText disabled=true pageFlowScope
From: Mark Dopheide [EMAIL PROTECTED]
Guidance required on this issue...
Realizing that when using tr:inputText and pageFlowScope (or saveState) the
readOnly (or disabled) attributes do not get submitted to the backing bean
as to the model, then...
What is recommended practice when these disabled values are to be
persisted? For example, if I am using pageFlowScope and in my backing bean
has something like:
User user = (User) app.getVariableResolver().resolveVariable(context,
user);
And my web pages contains:
label=#{text['registration.candidateId']} :
value=#{pageFlowScope.registration.candidateId}
disabled=true
contentStyle=margin: 1em 0 0 0;color: blue
required=true/
then this regCode attribute that is declared readOnly does not appear in
my User model in the backing bean. This is kind of a pain in the keyboard
;^)
pain in the keyboard... Ha! Now that's funny!
What is recommended practice in these situations? Certainly on the disabled
attributes is possible but this seems to lack the elegance
that I would expect.
I mean when using hibernate, etc I would just like to get the model (my
POJO) back from the view and do a userManager.save(user) but when readOnly
attributes are vacant then this isn't as easy as I think it should be.
Having a view object that gets transferred to my POJO just seems like so
much unnecessary code.
Any tips or hints on best practices related to this issue would be greatly
appreciated...
I was looking at the pageFlowScope the other day and found some good
documentation. You might have already seen this:
http://incubator.apache.org/adffaces/devguide/communicatingBetweenPages.html
It sounds like this scope is more granular than session scope but greater than
request. They are some how passing around a token in request that identifies a
new browser window or dialog. You have to stage the data in this scope
yourself like you might with session or request.
In your example above, you would find the user object as a managed bean or
maybe a spring bean.
User user = (User) app.getVariableResolver().resolveVariable(context,
user);
Lets say that we set the id using code instead of setter injection.
user.setCandidateId(111);
You would then use the trinidad context to push your user object into
pageFlowScope.
RequestContext requestContext = RequestContext.getCurrentInstance();
requestContext.getPageFlowScope().put(registration, user);
Your user object should exist in pageFlowScope until you terminate the dialog
or your session times out. If your user object already has a value in the
candidateId property, a disabled input component won't update the property.
Your candidateId in the user object should keep the prepopulated value and be
ready to save.
Does that sound correct?
Best regards to all,
Mark
Gary
Re: Comments into navigationPain
Hi, I am newbie to trinidad that I am using with Jboss. I have an xhtml page with the following code: .. f:view f:loadBundle basename=messages var=msgs / br/ h:form div class=menuBar tr:navigationPane hint=bar tr:commandNavigationItem immediate=true text= action=. / tr:commandNavigationItem immediate=true text= action=. / tr:commandNavigationItem immediate=true text= action=. / /tr:navigationPane /div and everything goes well. Since the page is generated by an application, I have to put some comments as placeholders for custom code: f:loadBundle basename=messages var=msgs / br/ h:form div class=menuBar tr:navigationPane hint=bar tr:commandNavigationItem immediate=true text= action=. / !-- Start comment -- !-- End comment -- tr:commandNavigationItem immediate=true text= action=. / tr:commandNavigationItem immediate=true text= action=. / /tr:navigationPane /div If I put the comments I get the following error message (on the jboss console) when the page is rendered: 21:55:22,076 ERROR [STDERR] Jan 17, 2007 9:55:22 PM org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.NavigationPaneRenderer renderContent SEVERE: Warning: illegal component hierarchy detected, expected UIXCommand but found another type of component instead. java.lang.ClassCastException: com.sun.facelets.tag.ui.ComponentRef Question are: 1) Can I use comments into commandNavigationItem and if yes how I have to use them 2) If I can't use comments is there any tag that can I use as place holder ? It appears that you are using facelets. Well, even if you used shale clay, you would not see the comments in the rendered mark-up (clay would just remove them if you used JSP like syntax). Some components are fussy about their children. They insist that their children are a specific type and that they have know behavior (As a parent I can relate to the know behavior part :-) . The comment is probably being added as a verbatim type of component. The RI has components like this. The javax.faces.HtmlSelectManyMenu component only likes children that are javax.faces.SelectItem or javax.faces.SelectItems. If you were using Clay, you could use the following directives to remove a block of markup: !-- ### clay:remove ### -- stuff that should be removed !-- ### /clay:remove ### -- Please, help me !!! Thank you Fab. Gary
Shale Clay/Trinidad
I've been experimenting with using Shale Clay for template composition using Trinidad components. Anyway, it requires a couple classes that handle all of the special method binding events. http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/java/org/apache/shale/clay/component/chain/trinidad/PropertyListenerCommand.java?view=markup This class has a dependency with commons chains. It also requires some xml configs. The clay configs are generated form the TLD's using a shale maven plugin and we also have a commons chains config. I was thinking that instead of adding yet another dependencies in Trinidad to provide native support like you have for Facelets, what would you think about a maven architecture type that would generate a base project with the exta bits? Gary
