[jira] Commented: (ORCHESTRA-20) single conversation
[ https://issues.apache.org/jira/browse/ORCHESTRA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585944#action_12585944 ] Mario Ivankovits commented on ORCHESTRA-20: --- Committed a fix for that too. Unfortunately this introduces a small binary incompatibility if one implemented a custom scope. In AbstractSpringOrchestraScope: protected String getConversationNameForBean(String beanName) has been changed to public String getConversationNameForBean(String beanName) single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586009#action_12586009 ] Mario Ivankovits commented on ORCHESTRA-19: --- First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, I one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586009#action_12586009 ] imario edited comment on ORCHESTRA-19 at 4/5/08 8:01 AM: --- First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, if one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. was (Author: imario): First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, I one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: orchestra and richfaces table scroller
Hi! Now, when I open the page in two browser windows it seems as if the datascroller is using the model in session scope, because when scrolling in one window, the selected range in the other window is also updated. I've tried to implement a StateManager using the ConversationContext as its place to store the state ... and it looks like it works. But the way I choose was to copy over the whole StateManager impl from myfaces. We are not very happy adding this hack to Orchestra ... Probably another hack will come ;-) Anyway, could you please try the latest myfaces 1.2.3 snapshot. I've fixed something in the state saving which might have been the real problem. Ciao, Mario
Re: [proposal] jsf validation with annotations
Hi! sev-en is a new jsf-extension. Looks Cool, I love it to see that a long standing idea now seems to be realized. You posted on the dev list .. cool .. you probably know we are developers too ... so .. where do we find the code? Or is it just a too-late April joke ;-) I think that would make a great new module for myfaces, no? Ciao, Mario
[jira] Created: (MYFACES-1850) component attributes problem with server side state saving with serialize in state = false
component attributes problem with server side state saving with serialize in state = false Key: MYFACES-1850 URL: https://issues.apache.org/jira/browse/MYFACES-1850 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.2, 1.1.5 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Critical When using server side state saving with serialize state in view=false all the saved states for the same view contains a shared reference to the component attribute map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-20) single conversation
single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585648#action_12585648 ] Mario Ivankovits commented on ORCHESTRA-19: --- The conversationContext URL parameter might hold the bottom conversationContext id. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585651#action_12585651 ] Mario Ivankovits commented on ORCHESTRA-19: --- The conversationContext api needs to be enhanced to get access to specific types of conversationContext. * byId (already there) * byName (user definable name) * byType (e.g. find the one responsible for the window data) refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
nasty problem in server side state saving
... with serialize in state disabled.
I've create a small test case which shows that the attributes map is
just copied over into the state. Which means that each and every
Component shares exactly the same map. Any change to this map will be
reflected in ALL saved states.
Correct would be to clone the map, but this must not work, at least a
shallow copy of the map should be saved (when serialize in
state=false) to avoid this problem.
What do you think?
public void testSaveInSessionWithoutSerialize() throws Exception
{
// create a fake viewRoot
UIViewRoot root = new UIViewRoot();
root.getAttributes().put(key, value);
// simulate server-side-state-saving without serialization
Object state = root.saveState(facesContext);
// restore view
UIViewRoot root1 = new UIViewRoot();
root1.restoreState(facesContext, state);
// restore view .. next request
UIViewRoot root2 = new UIViewRoot();
root2.restoreState(facesContext, state);
// chaange attribute in root1
root1.getAttributes().put(key, borken);
// and see it changed in root2 too
assertEquals(value, root2.getAttributes().get(key));
// and see it changed everywhere
assertEquals(value, root.getAttributes().get(key));
}
Ciao,
Mario
Re: nasty problem in server side state saving
Hi! It's because the wrong constructor in api's _ComponentAttributesMap class, it's assigning the map directly: So we do agree that this needs to be fixed? Then I'll do so ... Ciao, Mario
Re: JspStateManagerImpl into shared?
Ping! It seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi! Mario, you are not alone in hating the shared concept. ;-) Good! 1) has a super stable API That is true, that might be the hardest part. 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects Sure! 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Yepp! Problem here again is the name of such a lib: myfaces-commons-base? myfaces-commons-core? myfaces-commons-super? myfaces-commons-commons? ;-) I'd opt for myfaces-base, but to say the truth, I do not care about the name, whatever name it has will be good for me as long as the goal is the same. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. +1 I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! One rule can be to allow only stuff which itself directly implements a JSF API but do not provide any functionality on its own, you see, no enum converter or soo. Probably only abstract classes? Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? I'd like to see one project per version, e.g. myfaces-base11, myfaces-base12, myfaces-base20 (with namespaced package names: org.apache.myfaces.base11, etc) This might lead to code duplication for every new project, but is the only way I can think of making it possible for this project to succeed. It would not be nice if myfaces-base12 has to deal with backward-compatibility. Parts of myfaces-base12 MIGHT be backward-compatible, e.g. like any FacesContextWrapper. But there is no need for that, we can't forsee any future change e.g. in JSF 2.0 Ciao, Mario
Re: JspStateManagerImpl into shared?
Hi! Orchestra having its own JspStateManagerImpl sounds interesting though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. I thought about this like an optional feature one has to configure in their own faces-config.xml What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. +1 But that is not here yet! Is it not possible to apply the decorator pattern to whatever StateManager implementation the current JSF implementation provides? No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: [Orchestra] Mixed evironment installation problem - Complete Mail
Hi! However Orchestra does need a proper solution for this. I've created the following JIRA issue to track it: http://issues.apache.org/jira/browse/ORCHESTRA-18 Yes! What about creating a BasicSpringFrameworkAdapter which uses the same trick ApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext()); return appContext.getBean(pwdForgottenJSF); to lookup the beans in its getBean() function. Ciao, Mario
Re: [Orchestra] Mixed evironment installation problem - Complete Mail
Hi! I've committed a SpringBasicFrameworkAdapter, could you please give it a try and see if it works now. At the moment the flash scoped beans are not released after the JSP request! We will have a look how to fix that, but that should not be a major problem for now. Thanks! Ciao, Mario
Re: [Orchestra] Core15 release ?
Hi! are there any plans to release the core15 module ? soon :-) I would like open-source the @ConversationName annotation in core15 and then we should be ready. Volunteering doing the release then? Ciao, Mario
JspStateManagerImpl into shared?
Hi! Just to reiterate: I hate shared! ;-) Seriously, it seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! Thank's a lot for your response. What I would like to do is to be able to share a page (ant its backing bean) between 2 conversations types, like an activity définition can be shared between 2 process definition in BPM. For exemple, the select customer page can be shared between the 'send mail' and 'send invoice' use cases. I think I'm going to hack the source to see how I can achieve this. I see the use case of allowing to share the page-flow between different conversations. And probably something like this will come in Orchestra too. Though, exactly the use-case of select/search customer I'd solve in a different way. Why not have - lets say conversationA which then call the search customer page somehow which uses conversationSearch - at the end of conversationSearch you'll invalidate this conversation and pass back the primary key of the selected customer to conversationA. That way the conversationSearch data can be cleaned up as soon as the search has been finished. No need to clutter the persistence-context of conversationA with lots of entities fetched by conversationSearch. Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! Use of tag separateConversationContext allows to start a new conversation but it isn't really a nested conversation context, since it has to be done in a new browser window (no context stack). Am I right? Exactly! This is something we might implement in the (near?) future. This will also require you to define a page-flow in some way then - hopefully in a VERY easy - JSF like - way. Being able to maintain a conversation context stack is the first step in this direction I think. I think we can post a draft for discussion on what we think how to solve that with orchestra next week - watch out (or better, join) the dev list (if not done already). Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! Just to be clear, what you're saying is that you can't use the same view in more than one conversation at a time? At the moment: yes! As I wrote, this is something we will allow in the near future, but it would require to have a page-flow configuration. Hmmm probably the new refactored conversationContext will allow it programmatically too, not sure yet. Anyway, I wonder why this is such an important feature ... As I wrote, I think most cases can work with nested-conversation-emulation (tm ;-) ) and that will be much better in terms of memory usage - and also lowers the chance to work with stale objects if these conversations are bound to a persistence context. Can you please outline some use-cases so we can put them in consideration about how to solve that? Ciao, Mario
Re: orchestra and richfaces table scroller
Hi! Now I am wondering, would it theoretically be possible for Orchestra to also intervene in the server side state saving so that the component tree is stored in a conversation context? Theoretically yes. And this is also a wish others expressed already. We will investigate if it is possible to store the server-side state in the conversation context, but state-saving is not one of the gloriest in JSF. Ciao, Mario
Re: orchestra and richfaces table scroller
Hi Now I am wondering, would it theoretically be possible for Orchestra to also intervene in the server side state saving so that the component tree is stored in a conversation context? Theoretically yes. And this is also a wish others expressed already. We will investigate if it is possible to store the server-side state in the conversation context, but state-saving is not one of the gloriest in JSF. By copying the MyFaces StateManager and replacing its session access by conversationContext access it should easily possible to fix that problem. We can look at it in the next few days or contribute :-) Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! So, for example, while in the Relationships tab, I may want to quickly view or edit a Party. The view/edit Party view is usually in the Party tab. So, essentially I'm reusing the same page in a completely different flow. Now, in reality, I may end up using two different Facelet views that include the same composition, so this may not be an issue, but you get the idea... The question for me is if the Relationship and the Party stuff are being processed in the same conversation. If they are not - and I'd think to - then I'd do it that way: conversationRel navigtes to conversationParty by passing just the primary key of the party to this tab. The party bean then will load the party using its own persistence context. Both conversation should be manual conversations. The pro I see, if doing so, is, that if the user switch to the party tab later on - using the normal tab-navigation - the previously selected party is still there. Sort of smart application, no? Having a button start-over which will invalidate the conversationParty and bring up a fresh empty party-edit screen will then easily allow to do different things. I admit, I don't like it to think in page-flows in an webapp. Due to the webapp-navigation possibilities I often do not see it as a single flow, but more a graph of flows (better description?), Orchestras named conversations honor that fact not that bad I think. I often use two conversations per page. One manual-non-persistent conversation to hold the data to recreate the state and one access-persistent conversation to deal with persistence. The view-controller backing bean is then the access scoped object and gets the manual scoped state object injected. If the users clicks here and there and then back (not browser back ;-) ) to the page it looks as if the application is still aware about what the user wanted to do. But for sure, this will not fit everyones need, just my 2€ct. Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Mario Ivankovits schrieb: So, for example, while in the Relationships tab, I may want to quickly view or edit a Party. The view/edit Party view is usually in the Party tab. So, essentially I'm reusing the same page in a completely different flow. Oh - and there is a not very well known scope (some consider it a hack). The viewController scope. This allows the bean configured that way to reuse the same scope as your viewController is configured for - and thus use the same persistence context. You have to follow the viewController naming rules or use the @ViewController annotation to make that work. Not sure if this helps here, though. I normally use that for converter (configured via spring instead of faces-config.xml) to allow them to use the same persistence context to load data from the database. Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! If you're injecting conversation-scoped beans you're actually injecting a bean being tied to a specific conversation (i.e. you'd also have to copy bean definitions just referencing conversation-scoped beans, not only pages!). This is how spring works, no? You always put a bean in a scope and injection that somewhere else then. The only exception is the prototype scope. But this effectively means that this prototype-scoped bean shares the same lifetime of the bean it gets injected into. In my opinion that's a major impact in the architecture of Orchestra applications! Pretty much exclamation marks, having use-case descriptions would be more helpful to me ;-) I'd like to learn what makes this such a major impact that an Orchestra application needs to be coded differently? What beans do you put into conversation scope? I normally put just backing beans into any Orchestra scope - and you wouldn't share backing beans between pages, would you? Or are you work on service objects? But then Orchestra might not fit well indeed. But I have an idea how this could be solved eventually. Image such a config: bean name=pageA class=my.backing.Bean scope=conversation.access property name=service orchestra:elevate conversationName=pageA-service scope=conversation.manual ref=serviceBean / /property /bean bean name=serviceBean class=my.service.Bean scope=prototype / The trick is the conversationName here. The only thing-to-discuss is that if the pageA bean dies due to no longer being accessed any new instance of this page bean will reuse the same serviceBean instance (given it has not yet timed-out). I still would consider this as feature. You can fix that by using conversation.manual on the service bean too I think. At a start we can support something like that just with API calls (ConversationManager.elevate()) and then lets figure out how orchestra:elevate could be implemented. Volunteers? Ciao, Mario
country/zip show city problem [was: partial model update on ppr request]
Hi!
Sorry for the lengthy mail ... Solving this problem just made me crazy
so easy problem, and so complicate if not impossible solution with JSF.
Everything I toucht in the last couple of days had some
side-effect/influence on something else.
My simple country/zip immediate show city ppr problem drives me crazy.
I wonder why no one else wanted to solve that the nice way.
To sum up: You have a form with a couple of input fields, some of them
required. The field triple country/zip/city (within the form) should
behave as follows:
*) after country change - lookup and show city
*) after zip change - lookup and show city
*) allow to manually override the city
*) reset manually override city to automatich mode (using a special
commandLink)
After my latest changes to the ppr stuff I made things work, but not as
nicely as I wanted it to be - depending on the concrete view layout.
The most annoying things I experienced lately are:
1) the inlineMessage make the form not work correctly if the message is
going to replace one of the input controls ... means the value of
this field will not be transmitted (I can live without inlineMessage ...)
2) without inlineMessage, if the focus is within the city field, after
ppr the focus is lost (the input field has been readded to the form) and
you have to use the mouse to reset it.
3) The view (follows later) just looks ugly with some hacks (hidden
command buttons to make submitOnEvent happy)
The problem 2 is the one currently struggling me. As far as I know it is
not possible to get the element with the current focus.
If I would like to solve this problem, it seems if have to
a) attach an onfocus()/onblur() handler to each and every input element
and track the focus that way. You probably know how bad such things
interact with user supplied javascript (-1)
b) probably make the ajax call synchron which should hopefully avoid the
focus problem (+0)
c) get rid of this way at all (personally I don't like it to transfer
the whole component just to update the value) and introduce something
different at all (+1 I think)
Long story
Don't you think too that something like Shale Remoting (with a nicer
javascript client API) would be more helpful here?
You can solve that problem then easily and it should do the trick too.
What do you think?
Do you know any nice looking implementation of such a thing?
On java.net there is one (mabon), but it looks like it uses dojo which
then again will introduce some conflicts with the tomahawk-sandbox dojo.
Some javascript which again updates only the specific model fields and
executed a method then where you can use the return value in javascript
then again.
Something like:
// invoke(method, form-to-use, fields-to-send-and-process,
return-values-to-gather-from)
var returnArray[] =
BackingBeanExecutor.invoke(#{backingBeanName.method}, form,
{country, zip}, {city})
formField.value=returnArray[0];
In contrast to other remoting implementations this will really update
the model data and gather the value again from the components. Thus, the
converter/validation stuff will happen here too.
Ideas?
Ciao,
Mario
For those interested - the current view snipped:
h:outputLabel for=land value=Land/
h:selectOneMenu id=land value=#{prCustomerRegistration.land}
required=true
f:selectItems value=#{prCustomerRegistration.laender}/
s:submitOnEvent event=change for=searchCity/
/h:selectOneMenu
h:outputLabel for=plz value=Plz/
h:panelGroup
h:inputText id=plz value=#{prCustomerRegistration.plz} size=5
maxlength=5 required=true
s:submitOnEvent event=change for=searchCity/
/h:inputText
h:outputText value= Ort /
s:pprPanelGroup
partialTriggers=searchCity,searchCityOverride,searchCityReset
h:inputText id=ort value=#{prCustomerRegistration.ort}
size=30
maxlength=40
s:submitOnEvent event=change for=searchCityOverride/
/h:inputText
s:pprSubmit processComponentIds=land,plz,ort
h:commandLink id=searchCityReset
action=#{prCustomerRegistration.searchCityResetAction}
rendered=#{!prCustomerRegistration.useOrtAutomatic and not empty
prCustomerRegistration.ortAutomatic and prCustomerRegistration.ort ne
prCustomerRegistration.ortAutomatic}
h:outputText value=Ort
'#{prCustomerRegistration.ortAutomatic}' übernehmen./
/h:commandLink
/s:pprSubmit
/s:pprPanelGroup
s:pprSubmit processComponentIds=land,plz,ort
h:commandButton id=searchCityOverride
value=searchCityOverride
action=#{prCustomerRegistration.searchCityOverrideAction}
style=display:none;/
h:commandButton id=searchCity value=searchCity
ppr component update funcation hook [was: Re: country/zip show city problem]
Hi! What do you think about an enhancement for ppr which allows to customize the DOM update of the response? So, instead of the simple domElement.innerHtml=xx stuff, one is able to hook into that and provide his/hers own dom update. s:pprPanelGroup componentUpdateFunction=javascript-function-name/ where javascript-function-name points to a function with the signature of function(componentDataInResponse, targetDomElement) All the script handling will stay the same with this solution: If there is a script tag in the resulting innerHTML it will be executed. That way I'll be able to have a function like pprResponseCopyValuesOnly() which will not replace the whole DOM but just the wanted attributes of a given element. Later on we can also add a domUpdateFunction which will replace most of the ppr.handleCallback logic ... but that is another story. Thoughts? Ciao, Mario
Re: JSF 2.0 component set
Hi! Now it would be possible to update each component set to JSF 2.0... but a Tomahawk/JSF2 is expected to be backward compatible. So it would be difficult to radically change components or eliminate some duplicates... +1 I'd like to see this too, though, I think Oracle wouldn't give up Trinidad. And Tobago also is (too?) different, no? Ciao, Mario
myfaces code style - heads up
Hi! Something which happend to me too multiple times too, though, it is really hard to read a commit if it comes with a reformat of the source too. So, please: Before starting work on a source reformat it and commit this reformat only! Links to the code format settings can be found here [1] - (basically [2] anything else [3]). Do not let us discuss if this is the best way to do or not, just, lets do it that way. I'll attach to [1] what I think what fits best these needs in IDEA. Probably one can check if this matches with the already attached Eclipse formatting settings too. (By reformatting the PPR stuff in Eclipse and posting the difference so that we can either change the eclipse settings or the IDEA setup) Thanks! Ciao, Mario [1] http://wiki.apache.org/myfaces/MyFaces_Developer_Notes [2] http://www.apache.org/dev/styleguide.html [3] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
build failure due to site dependency
Hi! I have a build failure here as the site module can't find the 6-SNAPSHOT version of the (master?) pom. parent groupIdorg.apache.myfaces/groupId artifactIdmyfaces/artifactId version6-SNAPSHOT/version /parent If I change this back to version 5 it works. Do one know what's wrong here? Thanks! Ciao, Mario
[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup
[ https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583297#action_12583297 ] Mario Ivankovits commented on TOMAHAWK-1215: Why do you transfer the message and not simply the output of the messages component(s)? The problem I see with the current solution is that it do not honor any applied stylesheet/class configuration or a custom messages renderer. Instead you render on client-side - which seems too limiting to me. I see the use case of this solution when I think about the queueing stuff we talked about, but for the common use case of PPR (simple form transmissal) you do not need the messages machine readable. At least having an attribute messages=id,id,id which simply transfers the server side rendered output of those components would be great. Instead of naming it messages= you could also name it more general externalComponents= (or something like that) - Then it will be possible to configure components outside of the current pprPanelGroup - most likely the messages component. Add a communication channel for FacesMessages to the PPRPanelGroup -- Key: TOMAHAWK-1215 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1215 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Ernst Fastl Assignee: Ernst Fastl Fix For: 1.1.7-SNAPSHOT As any conventional JSF request PPR requests can lead to conversion and validation errors or other events which produce FacesMessages. The PPRPanelGroup should be enhanced to transport these messages in a separate channel (meaning a different type of child element in the xml-response). Optionally a messages-component could be build to which these messages can subsequently be added. Since this component might collect a lot of messages over various PPR requests it could have a clear button or something similar which enables the user to clear the messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup
[ https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583298#action_12583298 ] Mario Ivankovits commented on TOMAHAWK-1215: Is it true that you collect the messages of all configured components and then add/replace them on all the components on the client side? If you have multiple message components on the page this would mean that each component will receive ALL collected messages, no? Add a communication channel for FacesMessages to the PPRPanelGroup -- Key: TOMAHAWK-1215 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1215 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Ernst Fastl Assignee: Ernst Fastl Fix For: 1.1.7-SNAPSHOT As any conventional JSF request PPR requests can lead to conversion and validation errors or other events which produce FacesMessages. The PPRPanelGroup should be enhanced to transport these messages in a separate channel (meaning a different type of child element in the xml-response). Optionally a messages-component could be build to which these messages can subsequently be added. Since this component might collect a lot of messages over various PPR requests it could have a clear button or something similar which enables the user to clear the messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: partial model update on ppr request
Hi! The complicated thing is, that the pprSubmit enhancement would require a custom LifeCycle for PPR requests (why is it a PhaseListener by now?) I am investigating some time into that. In fact, the thing missing now is invokeOnComponent, didn't we have something like this in MyFaces already? Ciao, Mario
Re: Orchestra with Request Scope
Hi! In my app, there is an org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter that binds an entityManager to each request. With Orchestra do I really have to remove this filter? No. Orchestra does not help with request scoped beans. Mixing OEMIVF with Orchestra should work I think. For example I have a backing bean with request scope that lists entities, removing this filter adding orchestra, it starts failing. Another solution might be to put your request scoped bean into a flash scope, though, you have to be aware that then it might be possible to not see fresh data from the database as the ORM PersistenceContext caches the data. If you change data this is something you would like to have to utilize optimistic locking. If it is just to output data you then have to clear() the persistence context before fetching new data. Probably we should add an Orchestra managed request scope too Ciao, Mario
Re: partial model update on ppr request
Hi! The complicated thing is, that the pprSubmit enhancement would require a custom LifeCycle for PPR requests (why is it a PhaseListener by now?) I am investigating some time into that. Ok, I've committed something which did the trick. I've not yet fully replace the PhaseListener as first we have to check if the way I deal with the Lifecycle is stable enough. And that is exactly what I would like to ask you to review. I don't wanted to reimplement the whole lifecycle like Tobago did. More, I wanted to delegate to the original lifecycle and just change the bits I am interested in. And that was again not that easy probably something to change with JSF 2.0 - the Lifecycle class ... but thats another story. What I did is in PPRLifecycleFactory I return a decorated Lifecycle (PPRLifeCycle) which again just wrappes the FacesContext (in case of an PPR request) which then returns a wrapped UIViewRoot (PPRViewRootWrapper) and overrides processValidations and processUpdates if processComponentIds has been configured on pprSubmit. The bad about that solution is the wrapping stuff which might not be robust enough yet - especially with JSF 1.2. The good thing is that it will work with any other custom lifecycle already there. I tried to avoid any side-effect, but we will see how well that worked. pprSumit now also works with an embedded command control instead of being the child of one. That way I was able to intercept the queueEvent of the command component and configure things early enough. If things are going to work nicely we can put the code of PPRPhaseListener into the custom lifecycle. Please review! I'll put it in production by Monday, so more tests will follow then. Ciao, Mario
Re: orchestra conversation closed by stylesheet
Hi! Weblets for instance allows a zeroconf resource loading via phase listeners which trigger, usually this triggering is done before phase1, but there are portlet cases where it happens later. What are the JSF phases executed by weblets then? Probably we find a pattern which allows us to decide if it was a resource serving. Ciao, Mario
Re: orchestra conversation closed by stylesheet
Hi! many thanks for your tips. I checked the phase-listener solution, but it's a little dirty. The resource request skips phases 2-5. And the after RESTORE_VIEW callback is not called. In the before callback I do not know how to get the view id. As a solution i check the source component of the phase event. If it starts with org.ajax4jsf.resource.ResourceLifecycle I tell orchestra to ignore the request. It is really weird that serving a resource kicks in the jsf lifecycle. However, I think the first thing to do is to allow using regexp to match the request one would like to ignore. The second thing we (probably) should do is to ignore well known requests. Even if it is weird, I'd like to see Orchestra dealing with these requests out of the box. Nothing is more depressive than a library you would like to use which just do not (easily) work in you environment. JSF 2.0 might make things easier as then serving a resource is more standardized ... lets hope everyone is following that spec then. It's not beautiful but it seems to work. Yepp ... and it would not be any more beautiful if Orchestra do it that way, but if there is no other way ... well ... what the heck ... letz check for that thing. Would be great if you could post your final solution so that we could consider using it in Orchestra. Ciao, Mario
partial model update on ppr request
Hi! I have the need to do a partial model update for given components on ppr submit. (subform won't work here) I have a form with a couple of input fields, lets say FIELD_A, FIELD_B, FIELD_C, FIELD_D - all in one form. FIELD_A is required now, after something has been entered in FIELD_B, FIELD_C should be updated from the server using the data of FIELD_B. For this to work, I thought extending the new pprSubmit component with something like updateComponentIds=. You then will be able to have a commandLink (probably hidden) with s:pprSubmit updateComponentIds=FIELD_B / (comma separated list). The PprPhaseListener then has to do some magic to only update/validate those fields and skip the normal JSF phases. I'll going to add that stuff if no one objects. Ciao, Mario
Re: partial model update on ppr request
Hi!
The pprSubmit is something like a generic autoSubmit feature for
command components (see also autoSubmit attribute in trinidad).
? pprSubmit does nothing else than rendering the javascript to hook on
the new components too, no?
I do not understand what you mean with autoSubmit here.
Adding this feature to pprSubmit would somehow break the existing ppr
behavior, where the triggered components register themselves for
updates.
I do not change the existing ppr behavior, just how the data sent by it
will be processed on the server. If this will break the ppr philosophy
then I think the ppr is broken at all, isn't it?
Just to be sure everyone understand what I would like to have.
The interesting part of this view is:
* a single form
* a required customer name
* a country/zip pair which needs to be available in the model during ppr
* a city which will be computed out of the country/zip data during ppr
The problem is, that due to the required customer the ppr will not work
due to the validation error which will happen.
h:form
s:pprPanelGroup partialTrigger=lookupCity
t:panelGrid columns=2
h:outputText value=Customer Name /
h:inputText id=name value=#{bean.name} required=true /
h:outputText value=Country /
h:selectOneMenu id=country value=#{bean.country} /
h:outputText value=Zip /
h:inputText id=zip value=#{bean.zip} required=true
s:submitOnEvent event=change for=lookupCity /
/h:inputText
h:outputText value=City /
h:panelGroup
h:outputText id=cityAuto value=#{bean.cityAuto}
renderer=#{bean.cityAuto}/
h:commandButton action=#{bean.overrideCity}
renderer=#{bean.cityAuto}/
h:inputText id=cityMan value=#{bean.cityMan}
renderer=#{!bean.cityAuto} required=true /
h:commandButton action=#{bean.resetCityToAutomatic}
renderer=#{!bean.cityAuto}/
/h:panelGroup
/t:panelGrid
/s:pprPanelGroup
h:commandButton id=lookupCity action=#{bean.lookupCity} style=hidden
s:pprSubmit processComponentIds=country,zip /
/h:commandButton
h:commandButton action=#{bean.save} /
/h:form
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
Another possibility to fix that would be to enhance subForm to nicely
work in a nested mode so that you can have a subForm with multiple
subForms within and a logical name (new attribute) to group the subForms
together.
Then ppr as it is today might work then, the resulting view wouldn't
look nice though.
Or, using RichFaces with its ajax implementation which might allow this
already ... adding this library for just one function seems weird to me
though :-(
Ciao,
Mario
[jira] Commented: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
[ https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580264#action_12580264 ] Mario Ivankovits commented on TOMAHAWK-1214: re 1: I'd say we do it like the standard PPR. Using submitOnEvent a button can be clicked. PPR then has that button as partialTrigger configured and intercept the form submission. Now, instead of submitting the form its data will be put into the queue. The tricky thing here is, that on the response the viewState has to be taken and on next request the captured viewState needs to be replaced by the new one. re 2: Since it is a normal request, the normal JSF lifecycle will be executed. Another open question is, what about the response? I'd like to see yet another ppr option (queueResponseUpdate=lazy|eager) with default to eager. On eager, each response will be used to update the browser dom, on lazy, only the last response of a queue will be used. So, if the user executes many successive requests (e.g. through a barcode scanner), there is no need to refresh the user interface all the time. allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called queued=true|false. With true the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Hi! Hi, I like the approach. I am not very keen in annotated javadocs (which is error prone IMO) but that is just fine and I would say a better alternative to the XMLs (which are rather error prone too). However, it would be nice to have the builder library generic enough so we could use javadocs now and later have an alternative that uses real JDK5 annotations for whoever prefers that approach. Same for me! Thanks for the good work! +1 I like what Simon did too. I hope we can switch over to that soon. Ciao, Mario
[jira] Created: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called queued=true|false. With true the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AW: AW: Orchestra beginner question: conversation.flash behaves like request scope
Hi! Or do I have to define two separate beans in Spring: bean id=timeChainJSF_1 class=com.playoli.timeperiod.jsf.TimeChainJSF bean id=timeChainJSF_2 class=com.playoli.timeperiod.jsf.TimeChainJSF You need to use the two separate bean definitions approach. That gives your EL expressions the ability to say I want the instance from conversation X by referencing a different name. I would suggest names Are you using persistence from within the timeChainJSF bean? If not, you can inject the bean into your controller bean and use it through your controller. This is the solution I'd prefer. And last but not least (I know, Simon did not like it ;-) ), if you follow the ViewController concept (easiest using the @ViewController annotation), you are able to use the special viewController scope for such beans which means: For this bean use the same scope and conversation as your view controller does. So you have to define it only once, but get two different instances for each conversation. Ciao, Mario
Re: AW: AW: Orchestra beginner question: conversation.flash behaves like request scope
Mario Ivankovits schrieb: Are you using persistence from within the timeChainJSF bean? If not, you can inject the bean into your controller bean and use it through your controller. This is the solution I'd prefer. Should elaborate a little bit more about what I meant here. If possible, use the TimeChainJSF bean as prototype and inject that into your controller bean which has a conversation scope. That way, each controller bean will get its own TimeChainJSF bean which you'll be able to access through the controller than. Hope that makes it a little bit clearer. Ciao, Mario
Re: AW: Orchestra beginner question: conversation.flash behaves like request scope
Hi! I'll need to ask Matthias to update his example ;-) that is not mine. Mine is kind of up-to-date (facesgoodies) it is mario's project: http://code.google.com/p/myfaces-orchestra-goodies/ I totally forgot that there are examples too :-) I am getting old Ciao, Mario
Re: [Orchestra] Question to myFaces Orchestra configuration (Error on each request)
Hi Michael! ERROR 2008-03-17 08:24:35,110 [http-8000-Processor25] org.ajax4jsf.resource.ResourceLifecycle: Exception in PhaseListener, render view : beforePhase java.lang.IllegalArgumentException: No AccessScopeManager found. Probably you forgot to add import resource=classpath*:/META-INF/spring-orchestra-init.xml / to your spring configuration. at org.apache.myfaces.orchestra.conversation.AccessScopeManager.getInstance(AccessScopeManager.java:97) at org.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener.beforePhase(AccessScopePhaseListener.java:91) at org.ajax4jsf.resource.ResourceLifecycle.send(ResourceLifecycle.java:165) Is see nothing bad. You are using RichFaces? Which version? Hmmm for me, it seems like a Spring setup problem when it comes to resource delivery with ajax4jsf, but have not clue what that can be. Is it possible for you to provide a simple webapp setup with a hello-world example where we easily can debug the problem? Else I have to setup such a project first and this might take a day or two - and probably I might not be able to reproduce that bug then :-( Thanks! Ciao, Mario
[orchestra] Re: Bean Scope Problems
Hi! I already decided before you answered - I just search since 15 minutes for a myFaces + orchestra tutorial or example. Now I have to change my little application (to use spring and orchestra) - theres any archetype to create a myFaces+spring+orchestra webproject with maven? Currently there is just the myfaces orchestra examples [1] project where you can copy and paste the configuration easily. I hope that someone is going to contribute a nice looking tutorial sometimes :-) archetype would be great too Ciao, Mario [1] http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/examples
Re: [Orchestra] Question to myFaces Orchestra configuration (Error on each request)
Hi Mario yes, I'm using RichFaces 3.1.0. There is actually no real problem with the application (it works fine), but there is always this error in the log... Ah ... got it. You have to configure the DelegatingVariableResolver in your faces-config.xml to make the variable lookup of beans configured in spring work correctly. Some bits missing in our documentation it seems. With: application variable-resolverorg.springframework.web.jsf.DelegatingVariableResolver/variable-resolver /application your exception is gone. Thanks for providing your application! That made it easy to figure out what was wrong. Ciao, Mario I sent you my application as an attachment. Regards Michael -Ursprüngliche Nachricht- Von: Mario Ivankovits [mailto:[EMAIL PROTECTED] Gesendet: Montag, 17. März 2008 11:42 An: MyFaces Discussion Betreff: Re: [Orchestra] Question to myFaces Orchestra configuration (Error on each request) Hi Michael! ERROR 2008-03-17 08:24:35,110 [http-8000-Processor25] org.ajax4jsf.resource.ResourceLifecycle: Exception in PhaseListener, render view : beforePhase java.lang.IllegalArgumentException: No AccessScopeManager found. Probably you forgot to add import resource=classpath*:/META-INF/spring-orchestra-init.xml / to your spring configuration. at org.apache.myfaces.orchestra.conversation.AccessScopeManager.getInstance(AccessScopeManager.java:97) at org.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener.beforePhase(AccessScopePhaseListener.java:91) at org.ajax4jsf.resource.ResourceLifecycle.send(ResourceLifecycle.java:165) Is see nothing bad. You are using RichFaces? Which version? Hmmm for me, it seems like a Spring setup problem when it comes to resource delivery with ajax4jsf, but have not clue what that can be. Is it possible for you to provide a simple webapp setup with a hello-world example where we easily can debug the problem? Else I have to setup such a project first and this might take a day or two - and probably I might not be able to reproduce that bug then :-( Thanks! Ciao, Mario
Re: [vfs] VFS 1.0 CIFS
Hi! What's the recommended way of using commons-vfs 1.0 with CIFS support? You mean where to get the SMB provider from? Supposed to be in the vfs sandbox ...Mario? Sorry for being late, wasn't able to connect to our mailserver through the JSFDays conference network. Yepp, still in the sandbox. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VFS 1.0 CIFS
Hi! Is there a problem with placing the jar in http://people.apache.org/repo/m2-snapshot-repository/ Hmmm shouldn't this be something the nightly build should do already? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: announcement: Orchestra Core 1.1 released
Gratulation Simon. Great work :-) Mario -Original Message- From: simon [EMAIL PROTECTED] Date: Wednesday, Mär 12, 2008 8:00 am Subject: announcement: Orchestra Core 1.1 released To: Reply-MyFaces Discussion [EMAIL PROTECTED]To: MyFaces Discussion [EMAIL PROTECTED] The Apache MyFaces Orchestra team is pleased to announce the release of Apache MyFaces Orchestra Core 1.1. Apache MyFaces Orchestra is a library which provides a new scope called conversation scope to your web based applications. Plain conversation scopes are useful, but in addition conversation scopes can have an associated ORM persistence-context; this simplifies building applications that interact with databases, and helps to solve the LazyInitializationException problem. Get a full overview at Orchestra's homepage [1]. The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Have fun! Regards, Simon [1] http://myfaces.apache.org/orchestra
[jira] Commented: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577464#action_12577464
]
Mario Ivankovits commented on ORCHESTRA-17:
---
If I understand your patch correctly this thing will no longer work with plain
jsp, will it?
Some applications mix jsp and jsf pages, even if the jsp page is just a
bridge or something like that. I (we) wanted to support such setup.
But probably I missed some things ;-)
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Assignee: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [vote] [orchestra] release Core 1.1
Hi! The tar.gz and zip archives are deployed at [3] LICENSE.txt and NOTICE.txt are missing from, at least, the tar.gz archive. +1 when fixed. Not so important, but, it looks like these archives are a mixture of -bin and -src (which is fine I think), but no class files beside the jar are in there, though, the sources are in there packed and unpacked. Shouldn't the class files be added there too. Ciao, Mario
Re: [all] GSoC
Hi! Any idea for GSoC [1]? I think it would be worth participating VFS or IO: File Alteration Monitor with native support (I can sponsor some basic code-base for linux). If it is located in IO or in another package it should be possible to plugin VFS. Means, should not deal with plain java.io.File only as JCIFS (Samba) might support somehting like this for network shares too. VFS: Native File-System implementation for linux/windows/mac for performance reasons. The Eclipse guys did something in this area to avoid successive stat calls etc. Should make things a little bit faster. Though, that one would not be on my top list. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [orchestra] plans
Hi! +1 very good idea! Are those +1 due to the fact that you think that Orchestra is not the best place where such a component is located (which I understood), or is it that this component is still missunderstood ( :-( ) ? Fact is, that this component is a great timesaver when it comes to build master-data edit/view/list paged - typical CRUD stuff. Together with facelets templating and a little bit of base code creating new pages is just a matter of minutes and the best - these pages automatically follow the changes of the beans it creates (at runtime) the view for. Ciao, Mario
Re: [orchestra] plans
Hi! 2) release of orchestra-core15-1.0 We're working on it, but there's quite a lot of effort still needed. It all works (and is being used in production) but needs a lot of polishing before a stable API can be declared. Probably a couple of months away.. Really months? What do you plan to change/polish? As it is now, probably yes. The dynaForm stuff is really a hughe code-base needing some thoughts to being sure having a stable api. What we can think of moving the dynaForm stuff into the Orchestra sandbox. Then core15 should be a no-brainer for a release. This might make sense as thoughts are to merge the dynaForm stuff with another project. I'll kick off a discussion about it soon. Ciao, Mario
open link in new window prevention
Hi! Is there any reason that the MyFaces command link is rendered with href=# and onlclick=return xxx() instead of href=javascript: ? It seems, the latter will make the open link in new window feature of some browsers stopping to work. Which is what I'd like to have. What do you think about a context parameter e.g. org.apache.myfaces.OPEN_NEW_WINDOW_PREVENTION=true|false which will change how the commandLink renders the link? The default can be false to be compatible to the current behavior, though, I think defaulting to true wouldn't be that bad. What do you think? Ciao, Mario
Re: open link in new window prevention
Hi! Why do you say that some browsers can't open the link in a new window? No, I do not think that this is what I said, at least, I didn't wanted to say that. You probably know the right mouse click/open link in new window function of the browsers? You probably also know that this is a major impact to your application as then both windows share the same session. If your application keep some session data your application is much likely to fail at some point. Now, it seems there is a way to prevent the browser from being able to open a new window that way by rendering href=javascript: stuff instead of href=#. Using the target= attribute of the form and or link allows you to control what happens, e.g. with orchestra stripping the conversationContext url parameter and everything is fine (given that you do not store something in the session but only in an conversation and/or the conversationContext). But that is another story. Ciao, Mario
Re: [jira] Resolved: (TOBAGO-619) Avoid usages of javascript:false in iframe src attribute
Hi! May I ask what was the problem with this javascript:false stuff? And how do you avoid the dreaded message on https pages now? Do you point to an empty page now? Ciao, Mario [ https://issues.apache.org/jira/browse/TOBAGO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-619. -- Resolution: Fixed Avoid usages of javascript:false in iframe src attribute Key: TOBAGO-619 URL: https://issues.apache.org/jira/browse/TOBAGO-619 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.0.14 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.15, 1.1.0 -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [jira] Resolved: (TOBAGO-619) Avoid usages of javascript:false in iframe src attribute
Hi! May I ask what was the problem with this javascript:false stuff? And how do you avoid the dreaded message on https pages now? Do you point to an empty page now? Ok, forget it. I see what happens. The browser will output false within the frame. javascript:void(0) seems to do the trick. Ciao, Mario Ciao, Mario [ https://issues.apache.org/jira/browse/TOBAGO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-619. -- Resolution: Fixed Avoid usages of javascript:false in iframe src attribute Key: TOBAGO-619 URL: https://issues.apache.org/jira/browse/TOBAGO-619 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.0.14 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.15, 1.1.0 -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: open link in new window prevention
Hi! Is there any reason that the MyFaces command link is rendered with href=# and onlclick=return xxx() instead of href=javascript: ? It seems to me the right thing to do is to simply change the href=# to href=javascript:void(0). I think we can do that, no? Ciao, Mario
[jira] Issue Comment Edited: (MYFACES-1831) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener
[ https://issues.apache.org/jira/browse/MYFACES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574694#action_12574694 ] imario edited comment on MYFACES-1831 at 3/3/08 11:31 AM: Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If getCreated would have returned true, it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) was (Author: imario): Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If it would have returned getCreated it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener - Key: MYFACES-1831 URL: https://issues.apache.org/jira/browse/MYFACES-1831 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Simon Kitching In testing I have found that t:updateActionListener works fine with MyFaces 1.1.x but is ignored with MyFaces 1.2.3-SNAPSHOT After debugging, I found that UIComponentClassicTagBase.getCreated is always returning true. This means that UpdateActionListenerTag always thinks its parent component is already configured, so does not attach an UpdateActionListener instance to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1831) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener
[ https://issues.apache.org/jira/browse/MYFACES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574694#action_12574694 ] Mario Ivankovits commented on MYFACES-1831: --- Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If it would have returned getCreated it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener - Key: MYFACES-1831 URL: https://issues.apache.org/jira/browse/MYFACES-1831 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Simon Kitching In testing I have found that t:updateActionListener works fine with MyFaces 1.1.x but is ignored with MyFaces 1.2.3-SNAPSHOT After debugging, I found that UIComponentClassicTagBase.getCreated is always returning true. This means that UpdateActionListenerTag always thinks its parent component is already configured, so does not attach an UpdateActionListener instance to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-16) Rendering Problem
[ https://issues.apache.org/jira/browse/ORCHESTRA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574249#action_12574249 ] Mario Ivankovits commented on ORCHESTRA-16: --- What I said ... You should see it only on the first response which happens after the session has been created. Tomcat then encodes the URL _and_ sets the cookie. With the next request both will be sent back to tomcat (given cookies are enabled with the broswer) and the ;jsessionid will no longer be added to the link. Given the bug reporter didn't provide any new information I am going to close this bug. Rendering Problem - Key: ORCHESTRA-16 URL: https://issues.apache.org/jira/browse/ORCHESTRA-16 Project: MyFaces Orchestra Issue Type: Bug Environment: Spring, Apache Orchestra, JSF RI 1.2, Custom Components Reporter: Miroslav Genov It seems that there is a problem when any control is trying to access servlet for rendering of an image. I have an image verification component which is rendered as: img id=loginForm:verification_image src=/jadm-web/resourceServlet;jsessionid=CB3A2751A2FEF9823DE59A281AFA1BF0?imgId=14590567251000conversationContext=1 alt= height=40 width=100 / Any idea why orchestra places ; after servlet name.? This is the code which I'm using to render the image element. String src = / + ResourceServlet.RESOURCE_SERVLET_MAPPING + ?imgId= + id; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: commons-vfs current status?
Hi! I've been using the project for the last 6 months or so and haven't seen very many commits or activity on JIRA. Is there intention for on going support? As long as no code work needs to be done I think support is still there. Unhappily VFS lacks of developers and my time is limited too. Still, I don't want to say VFS is dead. I still have hope that we manage to spend more time again or finally other developers jump up too. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (ORCHESTRA-16) Rendering Problem
[ https://issues.apache.org/jira/browse/ORCHESTRA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573021#action_12573021 ] Mario Ivankovits commented on ORCHESTRA-16: --- This has nothing to do with orchestra. The ;jsessionid will be added by the servlet container (tomcat) on the first response or always if cookies are disabled (either server side or client side). HttpServletResponse.encodeUrl [1] is responsible for this. Ciao, Mario [1] http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String) Rendering Problem - Key: ORCHESTRA-16 URL: https://issues.apache.org/jira/browse/ORCHESTRA-16 Project: MyFaces Orchestra Issue Type: Bug Environment: Spring, Apache Orchestra, JSF RI 1.2, Custom Components Reporter: Miroslav Genov It seems that there is a problem when any control is trying to access servlet for rendering of an image. I have an image verification component which is rendered as: img id=loginForm:verification_image src=/jadm-web/resourceServlet;jsessionid=CB3A2751A2FEF9823DE59A281AFA1BF0?imgId=14590567251000conversationContext=1 alt= height=40 width=100 / Any idea why orchestra places ; after servlet name.? This is the code which I'm using to render the image element. String src = / + ResourceServlet.RESOURCE_SERVLET_MAPPING + ?imgId= + id; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Interest in an AjaxTree
Hi!
public interface AjaxTreeDataProvider {
public List getRootNodes();
public List getChildNodes(String nodeString);
}
Shouldn't this be something like this:
public interface AjaxTreeDataProvider {
public List getRootNodes();
public List getChildNodes(Object node);
}
Where node is the instance of the parent?
And is it somehow possible to expand/collapse a tree node by default?
Wouldn't it be better to at least use tree2's TreeDataModel? Though, I
am not sure about that as I don't know the requirements of an Ajaxed
Tree. I just see the beauty of at least having the AjaxTree to be a
drop-in replacement for tree2.
Ciao,
Mario
Re: [orchestra] conversation-scoped converters
Sorry for top posting, the handy client makes it hard to make it right. What you have done so far is great I think. But there is a third way of configuring a converter. This is configuring a converter with its own tag, like dateTimeConverter. This allows you to configure this very instance of the converter. I don't know how it works exactly from top of my head. Probably it is very easy. As a first step our converter wrapper should save the state of the spring converter (if it is a StateHolder) too. Mario -Original Message- From: simon [EMAIL PROTECTED] Date: Sunday, Feb 17, 2008 9:08 am Subject: Re: [orchestra] conversation-scoped converters To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org On Sun, 2008-02-17 at 08:16 +0100, Mario Ivankovits wrote: If we find a way how these could work I wouldn't mind if we get rid of the current solution. Your wish is my command. When thinking about it, this one wasn't possible with my solution either. So, probably lets not put this as high priority on the todo list. Sorry Mario, I don't understand what you mean here. I thought your earlier email said that you still wanted to be able to configure a Converter on a component by using a nested tag (instead of just using the converter attribute). So yesterday I added a new tag to do this: orchestra:converter beanName=.../ It is already tested and added to svn. Is that sufficient, or do you still really want to be able to use the standard f:converter tag to pull in converters from the spring configuration? Regards, Simon
Re: [orchestra] conversation-scoped converters
Hi! But there is a third way of configuring a converter. This is configuring a converter with its own tag, like dateTimeConverter. This allows you to configure this very instance of the converter. We don't need to support pulling f:dateTimeConverter instances from Spring do we? Those standard converters will never need an Orchestra converstation context or persistence context... Corret! I haven't meant the standard converters. I just wanted to point out that you can have a tag to install a converter on a given component. I do not mean the f:converter tag but something like f:dateTimeConverter. So you can have a home-made converter tag to configure the converter and install it on the parent component at the same time. Are you talking about how to configure the orchestra SerializableConverter class as a wrapper around a converter? Uhm ... do we have to configure each converter that way now? Wouldn't be very appealing, will it? I think having it explicit like this is nicer than having magic converter creation that auto-wraps stuff. Firstly it gives people full control over the process; wrap or not wrap as they choose. And secondly it is very obvious what is going on, rather than making the existence of a SerializableConverter almost invisible. I think this thing is much like the aop:scoped-proxy stuff - we tried to get rid of this very single line and now we have to define two beans for just one converter!? Alternatively, in the default orchestra-spring-config.xml we could possibly define a Spring BeanPostProcessor that intercepts the creation of all beans of type Converter and returns a wrapped object. I would personally prefer the explicit approach though; more work for the user but less magic. I am not sure, I think it should work out of the box, at least when the converter has been placed into one of the Orchestra managed scopes - as we do with the scoped-proxy stuff. Note that not all converters will be suitable for wrapping in a SerializableConverter; any converter type that has state will not work this way because a new instance is created on deserialize. Yep, this is exactly what I tried to point out in my previous mail. If the converter implements the StateHolder interface the wrapper should save/restore the state too. I think this is the required first step to allow having the tag-converter-setup thing I outlined above. Ciao, Mario
Re: [orchestra] conversation-scoped converters
Hi!
It *is* useful to be able to create converters that have access to
conversation scopes, which in turn mean they need to be instantiated by
pulling them from Spring. But this syntax is already supported by jsf:
someComponent id=comp2 converter=#{convId}/
I don't think so. Isnt it that the value binding should return the converter id
instead of a concrete instance?
Also, I'd like to have the converter stuff implemented in a way which nicely
integrate into JSF - as it is today. Otherwise you have to create a new way to
define such converters.
I don't want to make it more complicated just to avoid this JSF 1.2 oddity.
Isn't there any tool which will help us to check about any JSF 1.2 usage?
Ciao,
Mario
Re: [orchestra] conversation-scoped converters
Hi! Nice to see you back! Hehe - Thanks! Yea, and in after-ski-mode now ;-) Nope. The EL expression returns a Converter instance ah - wasn't aware from top of my head. Ok, so probably the ony thing we have to take a look at is how those converters work installed as child of a component using their own tag. If we find a way how these could work I wouldn't mind if we get rid of the current solution. Ciao, Mario
Re: [orchestra] conversation-scoped converters
Hi! Go on, rub it in .. I've been spending all my spare time working on an Orchestra release :-) That's fun too, isn't it ;-) If we find a way how these could work I wouldn't mind if we get rid of the current solution. Your wish is my command. When thinking about it, this one wasn't possible with my solution either. So, probably lets not put this as high priority on the todo list. Ciao, Mario
myfaces template structure [was: svn commit: r627191 - in /myfaces/tomahawk/branches/1_2_0/core/src/main/java/...]
Hi!
Being on vacation it is hard to follow the actual discussions, so, sorry
if I missed something along the lines.
While the fact that Leonardo flipped the object hierarchy can be treated
as genious idea (kudos!), I am not fully convinced that this is what we
want in the end.
Please, let me elaborate about another idea.
With JSF 1.2 in mind you might notice that you'll always see a
ValueExpressionImpl (for real EL) or a ValueExpressionLiteral for ...
what a wonder ... for literals.
Thus, a component in an JSF 1.2+ environment will never have the member
set to any value if not used programatically, no?
If we backport this strategy to JSF 1.1 (by using something like a
ValueBindingLiteral) we can get rid of any member on the component.
This will fix any state saving issue as then the base class can utilize
the HashMap where all the values are stored.
If we salt all this with one of Simon's ideas to not to use a HashMap
but a simple ArrayList it might be even more performant than the
solution we use today.
Notice, by today a JSF 1.2 component will always have to lookup a Map to
get the value. What is normally fast enough will become a performance
bottleneck if called multiple of hundred times. Admitted, this is not
very common with JSF components, but, well, it might happen.
Until there it should work with myfaces-core and tomahawk.
The only difference the generator has to deal with is that with
myfaces-core the component needs to be generated and for tomahawk a
simple baseclass with mainly some static int-s to describe the property
position within the array. Means, for myfaces-core we have to deal with
developing with templates while for tomahawk we can move on with
something more comfortable.
One than has to extend this baseclass and put in all the getter/setter
to access this array list. For the first time the generator might be
able to generate this class to, afterwards it needs to be maintained
manually which is not thath much work. And the dreaded reflection bug is
fixed too.
The result might be something like:
class AbstractTreeComponent extends UIComponent
{
final int FIN_VALUE=0;
final int FIN_COLLAPSED=1;
... something more I do not think about yet
}
public class TreeComponent extends AbstractTreeComponent
{
public boolean getCollapsed()
{
return ComponentUtils.getBoolean(this, FIN_COLLAPSED);
}
public void setCollapsed(boolean collapsed)
{
return ComponentUtils.setBoolean(this, FIN_COLLAPSED, collapsed);
}
}
What might not be very transparent at the first glance is, that the
state will shrink (!) that way. Currently you have to save the attribute
map AND all the members mostly null, afterwards you just have to save
a merge of those both.
With the very minor manual overhead to generate the getter/setter you
gain a clean, well-known object hierarchy and many of the problems with
any of the other solutions are fixed. Notice: no one will ever forget to
implement the getter/setter as otherwise the data is not available
within the renderer.
Something critical I overlooked?
Ciao,
Mario
t:datatable rowId Namespace
Hi! The rowId on the t:datatable is rendered without namespace. Following this fact I've added a columnId to the t:column which will be rendered without namespace also. While I know that this is crap, I just have done it that way to be consistent in this area. However, my better half ;-) told me very forcfully that this is really, really crap and that this should be fixed instead of adding more *sucking* things :-D Seriously, I too think this should be fixed. But this might, no it *will*, break things used out there, probably css selectors, javascripts etc. What can we do to solve this the right way? Shall we add a forceRowId=true|false for backward compatibility, even if we know that the whole forceId stuff isn't that a good idea!? Or lets have a context-param which allows one to configure this more globally. Someting like org.apache.myfaces.BROKEN_ROW_ID=true|false where false is the default. Ciao, Mario
[jira] Resolved: (TOMAHAWK-1193) add columnId to t:column
[ https://issues.apache.org/jira/browse/TOMAHAWK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1193. Resolution: Fixed add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1193) add columnId to t:column
add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1193) add columnId to t:column
[ https://issues.apache.org/jira/browse/TOMAHAWK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566953#action_12566953 ] Mario Ivankovits commented on TOMAHAWK-1193: Together wit this bug the rowId on t:datatable has been fixed to be facelets compatible add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566531#action_12566531 ] Mario Ivankovits commented on ORCHESTRA-15: --- I've commited a try to fix this issue. By checking out Orchestra from svn using [1] you should be able to mvn install your own version. Afterwards you can copy the resulting jar to your project and give it a try. Or wait for the next nightly. I am not sure if there is any side effect I've overlooked, but a quick test showed me that the Orchestra at least started up again ;-) Ciao, Mario [1] http://svn.apache.org/repos/asf/myfaces/orchestra/trunk Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Priority: Blocker In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: rowId and columnId on t:column
Hi! Would one mind if I add these two new attributes to the t:column tag? Yes Okay RowID already exists on t:table Oh - great. Might work, just, that it is that weird implemented that it wont work with facelets. Anyone has some informations why the tag handler uses setStringProperty(component, JSFAttr.ROW_ID, _rowId); where ROW_ID is some strange string constant instead of the normal getter/setter on the component? I think I have to change this to make it work and to avoid to have a useles custom tag-handler for facelets. Also, the value of this rowId is simply rendered without any further id-like processing. Means, it goes 1:1 into the result html without any namespace. Seems odd to me too. But for my case it is not that bad that way ;-) As for columns, have you tested t:column id=a? Does not get renderer somewhere either. Well, now, when I am going to fix this too, does one expect, if this id has been set, that the id is reflected in the cell-id or does it seem clear that the id goes into the th? I think the first one is the one expected, but I can't use it that way. I'd prefer having a columnHeaderId on t:column - this id is simply rendered with the th element. Ciao, Mario
Re: embedded table
Hi! It so happens, I have been looking for this sort of a solution. :-) Yea, I wonder why no one else have had a need for this too. It is a common use-case in our application. In my case, I have a table with three columns, with three headings. snip / Do you mean something like this: A table with, say 10 columns. First column is a description and then 3x3 columns with some values. As header you'd like to have: 1) 4 columns where the first column is a spacer for the description columns and then 3 columns where each spans 3 detail columns to describe the group of the spanned columns 2) another header with 10 column to describe exactly each column of the column I am working on a solution for this too as I need exactly this kind of thing too. Header 2 should be possible with the current solution, just use f:facet name=header on either the master table or detail table depending on if you'd like to have the header repeated each time. Header 1 requires some additional thoughts, but I think I'll introduce someting like a facet name=headerStamp where you'll be able to define a header which a complete different set of columns. You just have to ensure that the number of columns (including all the callspan) match with all used tables. Ciao, Mario
rowId and columnId on t:column
Hi! Would one mind if I add these two new attributes to the t:column tag? rowId should go to the tr element and colId to the th element. As usual, the row index will be added to the rowId and the thing should follow the default getClientId semantic. (parent namespaces etc) I need this information for one of my javascripts which I try to make usable with JSF tables too. The javascript allows me to apply client-side calculations to some cells and the above information will be used to lookup the cells in a table-calulation-alike way. Ciao, Mario
Re: Portlet Environment and Orchestra
Hi! The short answer to your question is no, the bridge won't help you here. Portlet 1.0 didn't define support for filters or wrapping request/response objects. Hence initialization done in filters in the servlet environment should be rewritten/migrated to FacesContextFactory. This document does not talk about when to release the configured resources again, does it? Is there something in the spec which talks about when to release a ThreadLocal again? Ciao, Mario
Re: Portlet Environment and Orchestra
Hi! If you wrap the FacesContext, then maybe when FacesContext.release is called? Yep, good idea. Done so. Thanks! Ciao, Mario
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
Hi! I don't think this will be controversial - I find it a rather good basic introduction to the concepts behind JSF, actually. I too think that this is a good introduction for any newbie. Something you'll normally read in a book but now public for everyone. Ciao, Mario regards, Martin On Wed, Feb 6, 2008 at 12:03 AM, Matthias Wessendorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: haha :) On Feb 5, 2008 10:37 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: embedded table
Hi!
Sounds good - can you send your example again utilizing the
detailStamp approach if that fits?
So, not it is getting stressy again. I have a bad need for it now.
So, using the detailStamp approach it might look like:
t:datable var=group1 value=#{bean.data}
...
t:column colspan=10
t:outputText value=#{group1.headerValue} /
/t:column
f:facet name=detailStamp
t:datable var=group2 value=#{group1.groupData} embedded=true
t:column colspan=2
t:outputText value=#{group2.headerValue2} /
/t:column
t:column colspan=8
t:outputText value=#{group2.headerValue2} /
/t:column
f:facet name=detailStamp
t:datable var=detail value=#{group2.detailData}
embedded=true
t:column
t:outputText value=#{detail.value1} /
/t:column
t:column
t:outputText value=#{detail.value10} /
/t:column
/t:datable
/f:facet
/t:datable
/f:facet
/t:datable
Additionally I'd like to introduce a headerStamp and footerStamp which
renders into the head/foot of the table (if possible) and thus allows
you to have multi-row header/footer.
Effectively these new stamps might work with an embedded datatable only
(for now).
I'll start doing so now, ok?
Ciao,
Mario
[jira] Commented: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566287#action_12566287 ] Mario Ivankovits commented on TOMAHAWK-1181: Three new attribute on the datatable have been added: embedded true|false Render the table in the embedded mode (no table/thead/tfoot/th tags will be used) detailStampLocation after|before Render the detailStamp after of before the row of the master table. before allow you to treat the master table as a list of summs of the child tables data. detailStampExpandedDefault true|false Render all the details by default. No further special header handling for now, lets have a look if this is enough for now. allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1181. Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Mario Ivankovits allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How can I have more than one bean in an orchestra conversation
Hi! I have tried to define a name for my conversation but did not succeed. All I found in the documentation was the hint of some hidden id on page specs. In your spring config add the orchestra xsd beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:tx=http://www.springframework.org/schema/tx; xmlns:aop=http://www.springframework.org/schema/aop; xmlns:orchestra=http://myfaces.apache.org/orchestra; xsi:schemaLocation= http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd http://myfaces.apache.org/orchestra http://myfaces.apache.org/orchestra/orchestra.xsd; and then you'll be able to configure the conversation name bean name=bean2 class=org.apache.myfaces.examples.multibean.Bean2 scope=conversation.manual orchestra:conversationName=multibean /bean Ciao, Mario
Re: Portlet Environment and Orchestra
Hi! I have access to FacesContext. The ExternalContext in case of Portlet Environment is - PortletExternalContextImpl and ofcourse in servlet environment it is ServletExternalContextImpl. So then, could you please try the following in your method: FrameworkAdapter.setCurrentInstance(new JsfFrameworkAdapter(null)); If it works then, I think it might be possible to fix this issue in a portlet friendly way, I've discussed with Simon already about moving initialization from the filter into the FacesContextFactory which obviously has been called even in the portlet environment. Ciao, Mario
Re: [orchestra] Spring 2.5
Hi! I think it would be nice also to see an attractive example application (separated from others) where Orchestra is used in conjunction with Absolutely, you might not being able to imagine how much I'd appreaciate such a demo application. Any plan to volunteer? :-) -minimal applicationContext.xml configuration: is possible to not require all that scope configuration?, Currently, no. But I think it would be possible to provide a simple bean factory which configures a default setup with spring. On the other hand, one strength (as I see) of Orchestra is it's flexibility. E.g. You can have Scopes with or without timeout, with our without auto-invalidation if bean has not been accessed and with or without persistence. Not sure what the default should be. My personal favorite is a scope with the following attributes. Invalidate if not accessed (previously flash-scope now access-scope) using timeout and persistence. But I am pretty sure that many other people would like to see a different default setup. -minimal faces-config: is it possible to move some of the application artifacts in the orchestra JAR? I'd like to keep them optional as they might have any influence to your application, though, the RedirectTracker is nearly a requirement to see messages if a conversation has timed-out and you use the @ConversationRequire annotation. Ciao, Mario
Re: MyFaces-Orchestra-ViewController : NullpointerException
Hi! currently I am using Orchestra in Portlet Environment and faced with ViewController exception: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at Seems like the same problem as in your other thread. Looks like I have to setup a protlet environment to debug things. It would be so helpful if you could provide a simple webapp to not have to setup all this by myself. Any chance? Else it might take some time as next week are holidays here and I am not sure if I manage to get enough free time and a good enough internet connection to being able to work on this. Ciao, Mario
Re: Portlet Environment and Orchestra
Hi! The short answer to your question is no, the bridge won't help you here. Portlet 1.0 didn't define support for filters or wrapping request/response objects. Hence initialization done in filters in the servlet environment should be rewritten/migrated to FacesContextFactory. Yep, I'll try to provide a (try of a) short-term fix tomorrow. Ciao, Mario
Re: Interest in an AjaxTree
Hi Matt! welcome tree3; Matthias is right. What are the differences to the existing tree2 component? Having tree2 enhanced to do ajaxed-node-fetching would greatly increase the chance that your patch will be accepted. We really would like to avoid to introduce yet another tree. Do you at least use the TreeModel of tree2? Else it would be a no-go for me. Tree2 can also be extended easily via existing ajax frameworks. Just that you can't have this ajaxed-node-fetching which would be really a nice feature I often whished to have. Yes, you can put tree2 in a ppr group (which I already did), but you have to fetch the whole tree in node toggling, no? Ciao, Mario
Re: Portlet Environment and Orchestra
Hi! currently we're prototyping a portlet application (liferay 4.33) with orchestra , JPA (Hibernate) and myFaces 1.1.5. Unhappily I have zero experience with portlets. If you could provide a simple webapp to test this thing it would greatly help, though, I know how much work it is to setup one. However, if possible somehow, please try the latest snapshot of Orchestra as we've changed how the FrameworkAdapter will be initialized. At least it gives us correct line numbers in the exception. The FrameworkAdapter brings me to the thing which might be needed to be fixed for the portlet environment, not sure though. If you have a look at the source of this class you'll see that there are just a handful of methods which needs to be implement, probably in a portlet friendly way. Could you please check if you have access to a FacesContext close before the method raising an exception? If so, you can stick with the JsfFrameworkAdapter and just need to find a way how to initialize it properly. If not, you have to create your own portlet friendly FrameworkAdapter wich allows you to get access to the session/request stuff required by Orchestra. Ciao, Mario
Re: [orchestra] Spring 2.5
Hi! Are there any plans about migration over Spring 2.5 in Orchestra? Orchestra itself is compatible with Spring 2.5. We use this combination in our projects. I'd like to see if Spring 2.5 can simplify orchestra configuration and if we can now completely declare bean throught annotations. What enhancement of Spring 2.5 do you mean that might allow this? I even didn't have the time to look at the annotations for bean definitions (Simon?), though, as far as I know the Spring framework I am pretty sure they implemented it in a way that the scope provider do not even know if the bean has been configured using the xml config or annotations. And do you think it is possible to have proxy scoped bean using annotation? If you use the latest Orchestra snapshot you do not have to use the aop:scoped-proxy anymore. This will be done automatically by Orchestra. For other proxy scoped beans, Simon tried something in this area, and as far as I remember with success. Even though Spring should provide such a annotation on their own, we probably can share our code if wanted. It is not part of Orchestra. Ciao, Mario
Re: Interest in an AjaxTree
Matt Tyson schrieb: I've got a Tree component that handles node expansions via Ajax. What do you think the interest would be in having this donated to Tomahawk? I'd say: Yes! Is it an all new component or did you enhance tree2? If you could open a jira ticket and add a patch so that we can see the technical details it would be great. Ciao, Mario
Re: submitOnEvent callback
Hi!
callback=#{bean.callbackFunction}
The callback should point to a javascript function name instead of a
bean method. callback is meant to be executed on the client.
This javascript method then should allow you to return true/false, on
false the click should not happen.
Ciao,
Mario
Re: [vfs] Inconsistent Behavior...
Hi James! I have fix for this I believe. Good to hear :-) - and - good catch! final String path = fileInfo != null fileInfo.isSymbolicLink() ? getParent().getName().getPath() + / + fileInfo.getLink() : relPath; final FTPFile[] tmpChildren = client.listFiles(path); Somewhere in VFS there is already some limited support for links, cant remember it yet, have to look into the source. The way you construct the new path does not honor the fact that the link might be an absolute path. I think VFS's link support can deal with that. If you have some additional time it would be great if you could figure that out please Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Hi! The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Welcome Bernhard ! --- Mario Ciao, Mario
