Re: about the pprPanelGroup component

[Ernst Fastl]

Another thing which is still missing for promotion of the pprPanelGroup
is the site-documentation (thats required for promotion as well).

There are also some issues left in JIRA which I wanted to fix before promotion
but didn't find the time so far...

speaking of TOMAHAWK-1226 TOMAHAWK-1227 TOMAHAWK-1228
and TOMAHAWK-1054 (although this is a tricky one and we may leave that
one for later on)

I already started to work on those issues but I'm not yet finished.

regarding the removal of dojo dependencies I fully agree with werner. We would
just need to implement a basic AJAX API (like dojo.io.bind) and some
event-handling
mechanism. Other components could probably also benefit from those.

kind regards

Ernst

On 5/20/08, Werner Punz [EMAIL PROTECTED] wrote:
 Gerald Müllan schrieb:
 Hi Hazem,

 Werner wants to migrate dojo to the latest release and tie it out of
 tomahawk.
 pprPanelGroup is relying on dojo, so i think it would be better to
 wait until werner has finished his work.

 Well it will be roughly a month before I am going to commit the first code
 (Sorry for not doing it public currently but I do not want to have
 people starting to use it before I do not have the core in place properly).

 But thinking of it it would make sense to remove the dojo dependencies
 out of the component and replace it with custom code.

 I think the component itself would make perfect sense in core tomahawk.

 So Hazem if you want to spend some time with it, this could be a perfect
 thing to do.

 The long term plan is to get dojo stuff into its own subproject and have
 Tomahawk as dependency free as possible.


 Werner

[jira] Commented: (TOMAHAWK-1226) PPRPanelGroup support for multiple forms in a page is broken

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587779#action_12587779
 ] 

Ernst Fastl commented on TOMAHAWK-1226:
---

In order to resolve this issue, I suggest that we introduce a PPRWindowCtrl 
which stores the triggers, patterns and so on.
PPRCtrl are at the moment connected to the form. That should only  be used for 
eventHandler connections. The rest should be
window bound IMO.

 PPRPanelGroup support for multiple forms in a page is broken
 

 Key: TOMAHAWK-1226
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1226
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Catalin Kormos
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


 When a triggering element is part of another form than a triggered element, 
 PPRPanelGroup doesn't behave well. The cause is related to where the 
 triggered element is kept, and a possible solution is to keep it in the 
 window object.
 Please look in ppr.js at 
 org.apache.myfaces.PPRCtrl.prototype.elementOnEventHandler and at 
 org.apache.myfaces.PPRCtrl.prototype.formSubmitReplacement; replacing 
 this.triggeredElement with window.triggeredElement fixes the problem, but it 
 might not be the best solution. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ppr component update funcation hook [was: Re: country/zip show city problem]

[Ernst Fastl]

Sounds like a good idea. While we are at that we could also add a general
before- and afterUpdateJSHook=jsFunction which will be executed
before and after the group has been updated. this way users could for instance
implement their own loading message display or just postprocess the updated
DOM-elements.

regards

Ernst

On Mon, Mar 31, 2008 at 8:06 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
 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: Ajax, pprPanelGroup and Portlets working together...

[Ernst Fastl]

Hi

duplicating code even if just a bare minimum doesn't sound good to me. Even if
option 2 means that 2 jars need to be copied for the configurator subsystem
I think they still belong there. Although probably not very
problematic it would seem
strange to me if components which are not directly related to the
configurator sub-system
would require myfaces-commons-configurator instead of myfaces-commons-utils.

So my +1 goes to option 2.

cheers

Ernst

On Fri, Mar 28, 2008 at 9:28 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
 Okay Okay already.. :)  I'll work on getting these in the commons
  somewhere.   The code for the configurators (and my nifty new, much
  nicer externalContextUtils) is done but I've been wishy washy about
  where things should go so I haven't created the poms yet.  Maybe I can
  work on that a bit this weekend.

  That said, I suppose I could ask the group for their preference.  The
  ExternalContextUtils is, undoubtedly, a very handy stand-alone piece of
  code.  Seems you guys really want to use it :)..  Where is really shines
  though (and I suspect most usecases which need this logic would
  eventually implement this) is when used with configurators.  The
  configurator system I've created will go into it's own module in the
  commons package.  Configurators can be used by simply dropping the jar
  into your classpath, but if the ExternalContextUtils was put into the
  commons-utils package (rather then the configurators), then you would
  need to drop in both.  So I guess here is my question for the community
  and perhaps it will keep me from being wishy washy and actually get this
  code checked in...

  1. Keep the ExternalContextUtils in the myfaces-commons-configurator
  jar.  Dropping this jar in your classpath gives you access to both the
  ExternalContextUtils as well as the configurator sub-system if you want
  to use it.

  2. Put ExternalContextUtils in the myfaces-commons-util jar, thus making
  it so that the configurator sub-system requires both jars to be copied
  into your classpath in order to enable configurators.

  3. Put ExternalContextUtils in the myfaces-commons-util jar and
  duplicate the bare minimum amount of code needed to support the
  configurators into the configurators package.  This way a project can
  drop in the configurator package if they want configurators, and the
  util package if they want ExternalContextUtils and both jars will
  operate independently of one another.

  IMO option 3 seemed kind of cool to start off with, but I was doing some
  experimenting with the configurators and found option 1 was much cleaner
  on some of the new API's I've been adding.  In other words, one of the
  things I did to make configurators run more efficiently is to take
  advantage of an enumeration provided by the ExternalContextUtils within
  the configurator API.  In order to use these enhancements as written, 1
  or 2 might be the best.

  Any preferences?

  Scott



  a clem wrote:
   yep, it seems that ExternalContextUtils is already  the abstraction on
   top of servlet and portlet apis i'm talking about. ;)
   And it is using reflection to dispatch the call either to portlet or
   servlet api. Using reflection means that ExternalContextUtils has only
   an 'implicit' dependency on both apis meaning that  type checking is
   delayed to runtime (like dynamic languages do). Going further, with
   this mechanism we could removed explicit dependency (compile time
   checked) on servlet api too!! ;)
   So sorry for my misunderstanding and Good idea Scott!! ;)
  
   On Fri, Mar 28, 2008 at 9:53 AM, a clem [EMAIL PROTECTED] wrote:
  
   On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl [EMAIL PROTECTED] wrote:
 +1 for ExternalContextUtils
  Good idea Scott

  In this case I wait for those utils before doing the changes in the
  PPRPhaseListener

  greez

  E



  On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan [EMAIL PROTECTED] 
 wrote:
   Take a look at Trinidad's ExternalContextUtils class.  It uses
reflection.  I'm also going to try to get something like this in 
 the
myfaces commons, probably in the configurator package if I end up
submitting my current code.
  
If you don't have time to find the ExternalContextUtils on your 
 own,
I'll try to post some source tomorrow.
  
Scott
  
  
  
Leonardo Uribe wrote:
 Hi

 I have seen lines like this on the attached files:

 //Don't do the rendering twice
 if (request instanceof PortletRequest 
 ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
 return;
 }

 The problem here is that doing this makes that tomahawk requires
 portlet api to work, in non portlet environments.

 The same problem is present on MYFACES-434 patch

[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583508#action_12583508
 ] 

Ernst Fastl commented on TOMAHAWK-1215:
---

At first I'd like to point out, that this is just a simple first shot and not 
the complete solution yet.

For simple cases the replaceMessages=id,id,id parameter can be used a thought 
above.

Seeing recent solutions indicate that we might deside to use custom lifecycles 
in PPR soon to only execute validation and conversion
for component subtrees which are included in the PPR response IMO we need 
option 2 appendMessages=id,id,id.
(I also think something like partial tree lifecycles will come in JSF 2.0)

If you have 2 subsequent PPR responses: 
-the first one executes the lifecycle for components A, and B and generates 
messages for those
-the second one executes the lifecycle for components C and D and also 
generates messages
you might not want to erase the messages for A and B by the second response.

Also for the queing  feature the need to display messages from multiple request 
at once has been expressed if I remember correctly.

So I think messages have to be treated differently than other components.

For the simple replace markup one the user could just wrap the messages in a 
PPRPanelGroup.

What we could use there is an alwaysUpdate=true parameter which simple 
includes updates for that component in any PPR 
response done for any other PPRPanelGroups on the page.

as for the externalComponents=id,id,id option - I think that would lead to 
some trouble
1. We cannot add the append or replace  or any other PPR parameters to just all 
other components
2. the way we update markup using innerHtml only works for components which 
  -a. render only a single parent DOM element (like the span from the 
PPRPanelGroup)
  -b. do not have any style attributes on those elements

To support extenalComponents=id,id,id we would need to support all types of 
components which is
really not that easy as it may sound - if anyone has ideas how to do that on 
the client side please tell

As for the styling - style and styleClass should be easy to include. More 
difficult is the message format and the messages
to which the messages-component listens. Therefore it would have been necessary 
to duplicate code from the messages-renderer
which I really would like to avoid.

I think the next step here is to extract the code which is responsible for 
identifying the messages for a messages component 
and format them correctly in some utils class which is then used by PPR and the 
messgages renderer.

 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: Ajax, pprPanelGroup and Portlets working together...

[Ernst Fastl]

+1 for ExternalContextUtils
Good idea Scott

In this case I wait for those utils before doing the changes in the
PPRPhaseListener

greez

E

On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan [EMAIL PROTECTED] wrote:
 Take a look at Trinidad's ExternalContextUtils class.  It uses
  reflection.  I'm also going to try to get something like this in the
  myfaces commons, probably in the configurator package if I end up
  submitting my current code.

  If you don't have time to find the ExternalContextUtils on your own,
  I'll try to post some source tomorrow.

  Scott



  Leonardo Uribe wrote:
   Hi
  
   I have seen lines like this on the attached files:
  
   //Don't do the rendering twice
   if (request instanceof PortletRequest 
   ((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
   return;
   }
  
   The problem here is that doing this makes that tomahawk requires
   portlet api to work, in non portlet environments.
  
   The same problem is present on MYFACES-434 patch.
  
   Can anyone suggest a way to avoid this dependency? or we should put
   portlet api as compile dependency for tomahawk?
  
   regards
  
   Leonardo Uribe
  
  

Re: partial model update on ppr request

[Ernst Fastl]

This seems to be addressing the more general JSF Problem immediate is
not enough
which the subForm tries to solve. I personally would dream of instead
of just required=true|false
requiredFor=buttonId1,buttonId2,... but that might just be an IDEA
for JSF 2.0.

The reason PPR uses a PhaseListener is that it was started and should
still work in JSF 1.1.
As far as I remember there were no custom lifecycles in 1.1.

The PhaseListener currently only kicks in before Render Response which
would be to late
for a feature like that.

I think the approach with updateComponentIds= could be implemented in the
PhaseListener as well if it also checks
after processDecodes for some sort of partialUpdate parameter and
then manually
invokes validation and conversion on the targeted components - and afterwards
just does, what it now does before render response

just my 2 cents

Ernst

On Thu, Mar 27, 2008 at 8:08 PM, Thomas Spiegl [EMAIL PROTECTED] wrote:
 ok, now I got it - nice approach +1



  On Thu, Mar 27, 2008 at 2:54 PM, Mari Ivankovits [EMAIL PROTECTED] wrote:
   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
  
  



  --


 http://www.irian.at

  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German

  Professional Support for Apache MyFaces

Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)

[Ernst Fastl]

I don't know if they are that specific already - but if we would put
up a JSF 2.0 wishlist in the wiki - maybe even with voting
we could add that idea there and tell the expert group to have a look
from time to time :)

cheers

E

On Thu, Mar 27, 2008 at 2:01 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

  On Thu, Mar 27, 2008 at 1:37 PM, Cagatay Civici

 [EMAIL PROTECTED] wrote:

  +1 for deprecating forceSpan and adding generic renderedIfEmpty.

  does one know if there will be an *empty* span for h:message in JSF 2.0 ?

  -M



  
  
  
   On Wed, Mar 26, 2008 at 1:34 AM, Ernst Fastl [EMAIL PROTECTED] wrote:
  
that would be another advantage of the simple default behavior to
render whatever (ul, table, span, ...) the component usually
renders also if there are no messages wouldn't it?
   
   
   
   
On Tue, Mar 25, 2008 at 11:51 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
 I would not recommend forceSpan as an attribute as the use of a span
  is renderer specific, not component specific. The component should not
  care how the renderer works



  On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl [EMAIL PROTECTED]
   wrote:
   Hi,
  
I like the idea of making that the default behavior. I think for
t:messages it should be save to do
so. As for h:messages I'm not sure how detailed the spec is there.
I'll better check that before
touching h:messages. I also don't know what mojarra does, but I
   would
guess that they do
the same thing as we do at the moment.
  
forceSpan would also work for me I guess. But if there it is ok to
ajust the default behavior
of t:messages I'd prefer that solution because its one parameter
   less
the user needs to
know and think about.
  
thanks for your ideas guys
  
Ernst
  
  
  
On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici
[EMAIL PROTECTED] wrote:
 Hi,

 For t:message and t:messages, there's already a forceSpan
   attribute, will it
 work for you Ernst?

 Cagatay



 On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED]
   wrote:

 
 
 
 
  On Tue, 2008-03-25 at 21:45 +0100, simon wrote:
   On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote:
Hi,
   
I would like to add renderedIfEmpty to the t:messages
   component which
per default is false (current behaviour)
The reason for that: To update/append FacesMessages to a
messages-component after AJAX requests (e.g. PPR)
it has to be possible to locate a DOM element to which this
   messages
can be appended.
   
One could also think of automatically adding a CSS-style
   display:none
if the empty table/list is rendered which is
reset by any JavaScript updates to the messages.
   
Alternatively we could create a new messages-component 
 which
   supports
 that.
   
If anybody can think of reasons why this parameter should
   not be added
please tell. Otherwise I'll file a JIRA issue
and start implementing on thursday evening.
  
   Does your second suggestion (CSS-style display:none) mean 
 to
   always
   render the div, but when there are no messages do:
 div id=.. style=display:none/
   and let javascript modify the style if messages need to be
   added to it
   after a ppr request?
  
   If so, I think that is nicer. Logically, it makes sense too;
   the
   h:messages has not been marked with rendered=false, it just
   happens to
   have no messages. So the div should be present, but hidden.
  
   And it means that no extra attribute is needed.
  
   I cannot imagine any application that would break because of
   the
   introduction of a div with display:none set.
 
  BTW, I was thinking about making this change in h:messages, not
   just in
  t:messages.
 
  However even if the change is done in core, the same
   functionality would
  still be needed in t:messages unless Sun Mojarra's h:messages
   component
  also renders a hidden div when empty. Any idea what Mojarra 
 does
   here?
 
  Regards,
  Simon
 
 


  

   
  
  



  --
  Matthias Wessendorf

  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org

Re: partial model update on ppr request

[Ernst Fastl]

Thanks for the info - I didn't know that.

Still - I'd just like to point out, that the initial IDEA of the
PPRPanelGroup was
to have a normal JSF-Lifecycle just with different rendering (partial
updates instead
of full page refreshes) so the PhaseListener before render response
appeared to be
the logical choice.

That doesn't mean that I would be against any other solution. At which
classes would
I need to look in order to get an idea of how the custom lifecycle
works and which
benefits we would have if we switch?

regards

Ernst

On Thu, Mar 27, 2008 at 10:06 PM, Volker Weber [EMAIL PROTECTED] wrote:
 Hi,

  custom lifecycles are possible in jsf1.1, tobago has a custom
  lifecycle which integrates the ajax (ppr) into the normal jsf
  lifcycle. in case of ajax the process* methods are only run on the
  partially requested components.


  Regards,
 Volker



  2008/3/27, Ernst Fastl [EMAIL PROTECTED]:


  This seems to be addressing the more general JSF Problem immediate is
not enough
which the subForm tries to solve. I personally would dream of instead
of just required=true|false
requiredFor=buttonId1,buttonId2,... but that might just be an IDEA
for JSF 2.0.
  
The reason PPR uses a PhaseListener is that it was started and should
still work in JSF 1.1.
As far as I remember there were no custom lifecycles in 1.1.
  
The PhaseListener currently only kicks in before Render Response which
would be to late
for a feature like that.
  
I think the approach with updateComponentIds= could be implemented in 
 the
PhaseListener as well if it also checks
after processDecodes for some sort of partialUpdate parameter and
then manually
invokes validation and conversion on the targeted components - and 
 afterwards
just does, what it now does before render response
  
just my 2 cents
  
  
Ernst
  
  
On Thu, Mar 27, 2008 at 8:08 PM, Thomas Spiegl [EMAIL PROTECTED] wrote:
 ok, now I got it - nice approach +1



  
 On Thu, Mar 27, 2008 at 2:54 PM, Mari Ivankovits [EMAIL PROTECTED] 
 wrote:
   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

[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582807#action_12582807
 ] 

Ernst Fastl commented on TOMAHAWK-1215:
---

solved with two new attributes:
-appendMessages - comma separated List of messages components to which messages 
will be appended
-replaceMessages - comma separated List of messages components for which 
messages will be replaced

 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] Resolved: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl resolved TOMAHAWK-1215.
---

   Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT

 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.

maven build broken

[Ernst Fastl]

hi guys,

seems like the maven build is broken. I get

[INFO] Failed to resolve artifact.

GroupId: org.apache.myfaces
ArtifactId: myfaces
Version: 5-SNAPSHOT

I would fix it myself - unfortunatly I'm not a maven export :(

has anyone a got a clue what happend
for me it worked just 2 days ago

cheers

Ernst

[jira] Created: (TOMAHAWK-1218) ClassCastException in PPRPhaseListener when submitting out of a dataTable

[Ernst Fastl (JIRA)]

ClassCastException in PPRPhaseListener when submitting out of a dataTable
-

 Key: TOMAHAWK-1218
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1218
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


Since findComponent returns UiComponentPerspective for client Ids within a 
dataTable
a ClassCastException happens in the PPRPhaseListener if a PPRPanelGroup is 
nested within a dataTable

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

make UIComponentPerspective.setupPerspective and UIComponentPerspective.teardownPerspective public

[Ernst Fastl]

Hi,

I think it would be good to have
UIComponentPerspective.setupPerspective and
UIComponentPerspective.teardownPerspective public.
Just take the ugly ugly workaround in the fix for TOMAHAWK-1218 as an
example why this would be a good idea.

Has anybody got objections or a different idea of how to solve
problems like that one?

cheers

Ernst

[jira] Resolved: (TOMAHAWK-1218) ClassCastException in PPRPhaseListener when submitting out of a dataTable

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl resolved TOMAHAWK-1218.
---

Resolution: Fixed

resolved by handling UiComponentPerspective correctly

 ClassCastException in PPRPhaseListener when submitting out of a dataTable
 -

 Key: TOMAHAWK-1218
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1218
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


 Since findComponent returns UiComponentPerspective for client Ids within a 
 dataTable
 a ClassCastException happens in the PPRPhaseListener if a PPRPanelGroup is 
 nested within a dataTable

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)

[Ernst Fastl]

Hi,

I would like to add renderedIfEmpty to the t:messages component which
per default is false (current behaviour)
The reason for that: To update/append FacesMessages to a
messages-component after AJAX requests (e.g. PPR)
it has to be possible to locate a DOM element to which this messages
can be appended.

One could also think of automatically adding a CSS-style display:none
if the empty table/list is rendered which is
reset by any JavaScript updates to the messages.

Alternatively we could create a new messages-component which supports that.

If anybody can think of reasons why this parameter should not be added
please tell. Otherwise I'll file a JIRA issue
and start implementing on thursday evening.

kind regards

Ernst

Re: Is it possible customize h:message

[Ernst Fastl]

Hi,

I believe the tomahawk component t:message does something similar to
what you want.
At least it displays the label instead of the id). Maybe you can use
that one or just check
org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer and do
something similar
in a custom renderer.

cheers

Ernst

On Wed, Mar 19, 2008 at 8:27 AM, prantor [EMAIL PROTECTED] wrote:

  Hi all
  I am using JSF myfaces implementation with RichFaces

  I have a code in rich modal panel like.

  h:inputText label=Client id=ClientId value=#{bean.client}
  required=true /
  rich:message for=ClientRecId
  f:facet name=passedMarkerh:graphicImage
  value=/images/ajax/passed.gif//f:facet
  f:facet name=errorMarkerh:graphicImage
  value=/images/ajax/error.gif//f:facet
  /rich:message

  I am expectiong that it will show message by Label like Client: Value is
  required. but it show message by ID like ClientId: Value is required.

  Why? Any kind of help regarding this issue is highly appreciated.
  --
  View this message in context: 
 http://www.nabble.com/Is-it-possible-customize-%3Ch%3Amessage%3E-tp16138403p16138403.html
  Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)

[Ernst Fastl]

Hi,

I like the idea of making that the default behavior. I think for
t:messages it should be save to do
so. As for h:messages I'm not sure how detailed the spec is there.
I'll better check that before
touching h:messages. I also don't know what mojarra does, but I would
guess that they do
the same thing as we do at the moment.

forceSpan would also work for me I guess. But if there it is ok to
ajust the default behavior
of t:messages I'd prefer that solution because its one parameter less
the user needs to
know and think about.

thanks for your ideas guys

Ernst

On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici
[EMAIL PROTECTED] wrote:
 Hi,

 For t:message and t:messages, there's already a forceSpan attribute, will it
 work for you Ernst?

 Cagatay



 On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote:

 
 
 
 
  On Tue, 2008-03-25 at 21:45 +0100, simon wrote:
   On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote:
Hi,
   
I would like to add renderedIfEmpty to the t:messages component which
per default is false (current behaviour)
The reason for that: To update/append FacesMessages to a
messages-component after AJAX requests (e.g. PPR)
it has to be possible to locate a DOM element to which this messages
can be appended.
   
One could also think of automatically adding a CSS-style display:none
if the empty table/list is rendered which is
reset by any JavaScript updates to the messages.
   
Alternatively we could create a new messages-component which supports
 that.
   
If anybody can think of reasons why this parameter should not be added
please tell. Otherwise I'll file a JIRA issue
and start implementing on thursday evening.
  
   Does your second suggestion (CSS-style display:none) mean to always
   render the div, but when there are no messages do:
 div id=.. style=display:none/
   and let javascript modify the style if messages need to be added to it
   after a ppr request?
  
   If so, I think that is nicer. Logically, it makes sense too; the
   h:messages has not been marked with rendered=false, it just happens to
   have no messages. So the div should be present, but hidden.
  
   And it means that no extra attribute is needed.
  
   I cannot imagine any application that would break because of the
   introduction of a div with display:none set.
 
  BTW, I was thinking about making this change in h:messages, not just in
  t:messages.
 
  However even if the change is done in core, the same functionality would
  still be needed in t:messages unless Sun Mojarra's h:messages component
  also renders a hidden div when empty. Any idea what Mojarra does here?
 
  Regards,
  Simon
 
 

Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)

[Ernst Fastl]

that would be another advantage of the simple default behavior to
render whatever (ul, table, span, ...) the component usually
renders also if there are no messages wouldn't it?

On Tue, Mar 25, 2008 at 11:51 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
 I would not recommend forceSpan as an attribute as the use of a span
  is renderer specific, not component specific. The component should not
  care how the renderer works



  On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl [EMAIL PROTECTED] wrote:
   Hi,
  
I like the idea of making that the default behavior. I think for
t:messages it should be save to do
so. As for h:messages I'm not sure how detailed the spec is there.
I'll better check that before
touching h:messages. I also don't know what mojarra does, but I would
guess that they do
the same thing as we do at the moment.
  
forceSpan would also work for me I guess. But if there it is ok to
ajust the default behavior
of t:messages I'd prefer that solution because its one parameter less
the user needs to
know and think about.
  
thanks for your ideas guys
  
Ernst
  
  
  
On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici
[EMAIL PROTECTED] wrote:
 Hi,

 For t:message and t:messages, there's already a forceSpan attribute, 
 will it
 work for you Ernst?

 Cagatay



 On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote:

 
 
 
 
  On Tue, 2008-03-25 at 21:45 +0100, simon wrote:
   On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote:
Hi,
   
I would like to add renderedIfEmpty to the t:messages component 
 which
per default is false (current behaviour)
The reason for that: To update/append FacesMessages to a
messages-component after AJAX requests (e.g. PPR)
it has to be possible to locate a DOM element to which this 
 messages
can be appended.
   
One could also think of automatically adding a CSS-style 
 display:none
if the empty table/list is rendered which is
reset by any JavaScript updates to the messages.
   
Alternatively we could create a new messages-component which 
 supports
 that.
   
If anybody can think of reasons why this parameter should not be 
 added
please tell. Otherwise I'll file a JIRA issue
and start implementing on thursday evening.
  
   Does your second suggestion (CSS-style display:none) mean to 
 always
   render the div, but when there are no messages do:
 div id=.. style=display:none/
   and let javascript modify the style if messages need to be added to 
 it
   after a ppr request?
  
   If so, I think that is nicer. Logically, it makes sense too; the
   h:messages has not been marked with rendered=false, it just happens 
 to
   have no messages. So the div should be present, but hidden.
  
   And it means that no extra attribute is needed.
  
   I cannot imagine any application that would break because of the
   introduction of a div with display:none set.
 
  BTW, I was thinking about making this change in h:messages, not just 
 in
  t:messages.
 
  However even if the change is done in core, the same functionality 
 would
  still be needed in t:messages unless Sun Mojarra's h:messages 
 component
  also renders a hidden div when empty. Any idea what Mojarra does here?
 
  Regards,
  Simon
 
 


  

Re: Ajax, pprPanelGroup and Portlets working together...

[Ernst Fastl]

Hi,

I just took a quick glance at the changes in the PPRPhaseListener.
What I've seen looks
alright so far and since I'm working on that class at the moment
anyway I'll be happy to
factor in those changes.

As for the DojoUtils, those are as far as I know mainly maintained by werner.
Maybe he wants to have a look there - otherwise I'll also take a look
at that too.

You are absolutely right when you say that our components should also work in
portlet environments. thanks for your contribution.

cheer

Ernst

On Mon, Mar 24, 2008 at 2:21 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
 Cool beans.  Be careful though before checking these patches into a mainline
 code base (maybe a sandbox or something).  This solution probably won't work
 for remote WSRP portals.  As for your second suggestion, I couldn't agree
 more.  The Trinidad configurators provide an ExternalContext specifically to
 keep the abstraction container agnostic.  You may wish to implement the
 ExternalContext in your change.

 Scott



 On Mon, Mar 24, 2008 at 5:15 AM, a clem [EMAIL PROTECTED] wrote:
  Hi,
 
  I ve made working pprPanelGroup in liferay portal. To do that, I had
  to patch 2 files of the core and sandbox distributions.
  - org/apache/myfaces/custom/dojo/DojoUtils.java
  - org/apache/myfaces/custom/ppr/PPRPhaseListener.java
 
  Basically the modifications consist to check wether the request is a
  portletrequest or a servletrequest.
  It would be nice if ajax related myfaces code could be completely
  servlet or portlet context agnostic, for example using a layer of
  abstraction on top of servlet and portlet apis.
 
  I also had to patch 6 files of the liferay code base to make the
  portal PPR aware. For those who are interested, just let me know.
  It is quite simple but it works nice and it is, I think, a more
  flexible and powerful approach than the IceFaces one to get Ajax
  working within your portlets.
 

[jira] Created: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup

[Ernst Fastl (JIRA)]

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


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: Redesigned MyFaces website preview

[Ernst Fastl]

Excellent work guys! Looks great!

On Wed, Mar 19, 2008 at 9:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
 Yeah, that would be most helpful I think..  Once again, good work.

  Scott


  Catalin Kormos wrote:
   Sure, that will be changed. On the current website the publish date is
   displayed the, i think we can leave it like that, right?
  
   regards,
   Catalin
  
   On Wed, Mar 19, 2008 at 10:17 PM, Scott O'Bryan [EMAIL PROTECTED]


  mailto:[EMAIL PROTECTED] wrote:
  
   I do have another followup comment.  At the top of the page is a
   version...  This makes total sense if we are navigating a project
   (like MyFaces core) but it makes less sense if the content is being
   retrieved from a source tree that doesn't have any releases (like the
   MyFaces and Portlet Bridge site projects).  Is that version tag part
   of a site template?  If so, I would say that when not navigating a
   project, this should be blank.
  
   Scott
  
   Scott O'Bryan wrote:
+1 from me.  Excellent work.
   
I also wouldn't mind switching to XDOC for the Download pages on the
portlet bridge if we have to, but I'd want to move the MyFaces
downloads page as well.  It's far to easy to do a cut and
   paste over
the new release block.  If we don't do this, I'm okay with the
limitations of APT regardless.
   
Catalin Kormos wrote:
I would like to ask for your opinion before starting to commit the
new MyFaces Maven skin (based on the designs Adonis provided).
   Please
have a look at [1] for a quick preview, it's not the entire
   website,
so most of the links don't work, but most of the elements that have
been customized can be seen.  It's a bit different from what
   you can
see at [2], on which the community agreed on, mainly because
   there is
not much / not at all freedom available for customizing the
   markup of
the sections in the main content. Also you can notice a difference
between some tables (for example between the ones on the downloads
page and the ones on the mailing lists page), as tables generated
from an APT doc, don't render th elements, but from XDoc docs
   they
are available (the XDoc format is much more flexible here, and in
general); the next release of Maven Doxia, as far as i've seen,
   will
fix the issue with the headers.
   
If you don't find anything in particular wrong and you agree
   that we
can live with these small issues for a while, i will apply the new
skin over all the projects, and add new logos where we have (for
example for the Portlet Bridge project).
   
[1] http://people.apache.org/~ckormos/myfaces/website/
   http://people.apache.org/%7Eckormos/myfaces/website/
http://people.apache.org/%7Eckormos/myfaces/website/
[2]
   
   
 http://people.apache.org/~ckormos/myfaces/vote/myfaces_vote_design_4.png
   
 http://people.apache.org/%7Eckormos/myfaces/vote/myfaces_vote_design_4.png
   
   
 http://people.apache.org/%7Eckormos/myfaces/vote/myfaces_vote_design_4.png
   
   
regards,
Catalin
   

Codebeat
www.codebeat.ro http://www.codebeat.ro http://www.codebeat.ro
   
  
  
  
  
   --
   
   Codebeat
   www.codebeat.ro http://www.codebeat.ro

Re: Redesigned MyFaces website preview

[Ernst Fastl]

+1 from me

our demos may functually be complete but almost all other component vendors
enhance the user experience in their demos greatly by proper design

also looks better in presentations

I think we would attract more users with nicer CSS in the demos

Ernst

On Wed, Mar 19, 2008 at 10:08 PM, Cagatay Civici
[EMAIL PROTECTED] wrote:
 We definitely need the same for library suite demos for trinidad and
 tomahawk.

 Compared to other libs' demos like richfaces or icefaces, our example
 projects doesn't look attractive.

 Cagatay



 On Wed, Mar 19, 2008 at 10:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
  Yeah, that would be most helpful I think..  Once again, good work.
 
  Scott
 
 
  Catalin Kormos wrote:
   Sure, that will be changed. On the current website the publish date is
   displayed the, i think we can leave it like that, right?
  
   regards,
   Catalin
  
   On Wed, Mar 19, 2008 at 10:17 PM, Scott O'Bryan [EMAIL PROTECTED]
 
 
 
   mailto:[EMAIL PROTECTED] wrote:
  
   I do have another followup comment.  At the top of the page is a
   version...  This makes total sense if we are navigating a project
   (like MyFaces core) but it makes less sense if the content is being
   retrieved from a source tree that doesn't have any releases (like
 the
   MyFaces and Portlet Bridge site projects).  Is that version tag
 part
   of a site template?  If so, I would say that when not navigating a
   project, this should be blank.
  
   Scott
  
   Scott O'Bryan wrote:
+1 from me.  Excellent work.
   
I also wouldn't mind switching to XDOC for the Download pages on
 the
portlet bridge if we have to, but I'd want to move the MyFaces
downloads page as well.  It's far to easy to do a cut and
   paste over
the new release block.  If we don't do this, I'm okay with the
limitations of APT regardless.
   
Catalin Kormos wrote:
I would like to ask for your opinion before starting to commit
 the
new MyFaces Maven skin (based on the designs Adonis provided).
   Please
have a look at [1] for a quick preview, it's not the entire
   website,
so most of the links don't work, but most of the elements that
 have
been customized can be seen.  It's a bit different from what
   you can
see at [2], on which the community agreed on, mainly because
   there is
not much / not at all freedom available for customizing the
   markup of
the sections in the main content. Also you can notice a
 difference
between some tables (for example between the ones on the
 downloads
page and the ones on the mailing lists page), as tables generated
from an APT doc, don't render th elements, but from XDoc docs
   they
are available (the XDoc format is much more flexible here, and in
general); the next release of Maven Doxia, as far as i've seen,
   will
fix the issue with the headers.
   
If you don't find anything in particular wrong and you agree
   that we
can live with these small issues for a while, i will apply the
 new
skin over all the projects, and add new logos where we have (for
example for the Portlet Bridge project).
   
[1] http://people.apache.org/~ckormos/myfaces/website/
   http://people.apache.org/%7Eckormos/myfaces/website/
http://people.apache.org/%7Eckormos/myfaces/website/
[2]
   
  
 http://people.apache.org/~ckormos/myfaces/vote/myfaces_vote_design_4.png
  
 http://people.apache.org/%7Eckormos/myfaces/vote/myfaces_vote_design_4.png
   
  
 http://people.apache.org/%7Eckormos/myfaces/vote/myfaces_vote_design_4.png
   
   
regards,
Catalin
   

Codebeat
www.codebeat.ro http://www.codebeat.ro http://www.codebeat.ro
   
  
  
  
  
   --
   
   Codebeat
   www.codebeat.ro http://www.codebeat.ro
 
 

[jira] Commented: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580077#action_12580077
 ] 

Ernst Fastl commented on TOMAHAWK-1214:
---

Sound like a cool feature. There are 2 things which I do not yet completely 
understand:

1.) What is the event which leads to the storage of the form data in the queue
  -a button which is clicked?
  -every time a value of one of the inputs changed?

2.) What is the acting component which submits one set of queue? what should 
happen after that?
  -just updateModel?
  -actionListener or action?
  -will be done by valueChangeListeners of the input components?

could also be that I misunderstood the idea - in any case - further 
clarification would be nice :-)


 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: myFaces vs MyFaces ... what do you think ?

[Ernst Fastl]

I would also go for the M since it is a name and not an instance variable :)

On Dec 10, 2007 12:59 AM, Catalin Kormos [EMAIL PROTECTED] wrote:
 I also prefer M, as i always known MyFaces like that, and agreed with
 Mathias for the naming convention Apache MyFaces, etc instead of Apache
 myFaces, etc.

 regards,
 Catalin



 On Dec 9, 2007 2:18 PM, Hazem Saleh [EMAIL PROTECTED] wrote:
  +1 for M  :).
 
 
 
 
  On Dec 9, 2007 1:34 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   I'd always call it:
   Apache MyFaces Tomahawk
   Apache MyFaces Tobago
   Apache MyFaces Trinidad
   Apache MyFaces Blah
   ...
  
  
   On Dec 9, 2007 3:25 AM, Adonis Raduca [EMAIL PROTECTED] 
 wrote:
   
   
I think that is important to have a consistent naming strategy for all
myFaces (MyFaces) projects. For example I thought to one similar with
 the
Java naming convention for the instance variables.
Something like:
myFaces
tobago
tomahawk
…
   
   
I think that once the naming strategy will be in place must be
 respected
everywhere (logos, text stuff, etc.)
   
Adonis
   
   
   
On 12/8/07, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 Eh, I think that is total different beast.
 We all work here as individuals and it is ok to misspell names...

 But... starting to misspell the own project, is ... yes, confusing.

 -M

 On Dec 8, 2007 8:47 PM, Bruno Aranda  [EMAIL PROTECTED] wrote:
  I am not so sure if it is the same writing the official name of
 the
  project (Apache MyFaces) that what we find in the (myFaceS). For
  instance, most of the time we write in this list Oracle instead
 of
  ORACLE (logo). I guess we should just choose which one is more
  appealing to us, so just vote and let the outcome be our choice :)
 
  My 2 cents,
 
  Bruno
 
 
  On 08/12/2007, Rahul Akolkar [EMAIL PROTECTED] wrote:
   On 12/8/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
I too, and I think it is confusing, when we start to write it
wrong..
   
   snip/
  
   Indeed, its important to get the name right (case et al),
 especially
   in the logo :-)
  
   -Rahul
  
 



 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org

   
   
  
  
  
   --
  
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
 
 
 
  --
  Hazem Ahmed Saleh Ahmed
  http://www.jroller.com/page/HazemBlog
 

Re: New AddResource handler: DojoAddResource

[Ernst Fastl]

Sounds great!

I believe this will be helpful in dealing with new JavaScript includes in PPR
responses ( TOMAHAWK-1054 ). Looking forward to checking it out :)

regards

Ernst

On 9/21/07, Mario Ivankovits [EMAIL PROTECTED] wrote:

  Ok, I've found the first problem, the stylesheets were inserted AFTER
  all the other stylesheets, so any overloaded stylesheet will be lost.
 
  Will think about if this can be fixed 
 
 fixed!

 Ciao,
 Mario

Re: [tomahaw] ppr problems with log and tree2

[Ernst Fastl]

Hi Mario!

thanks for pointing out this issues.

I must have missed the point where
this log got in - my guess is that it can optionally be defined or turned on
in dojo or something. However I would think a check wether or not the object
is defined before using it cannot hurt.

@whoever did this - comments ? ;-)

I also like the suggestion of caching the patterns themselves and re-matching
them against all inputs within updated areas.

I have a relatively tight schedule this week, but I'll try to squeeze
it in on the
weekend.

greez

Ernst

On 9/19/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!

 First, I've commented the using of the log stuff as it seems normally
 thre is no log object around, at least I don't know where.

 From our ppr.js:

  if(formElement)
  this._addEventHandler(formElement, connectToEventArr, eventHandler);
 -else
 +   /* where is the log?
 +   else
  log.error(Input element with id : +formElementId + not found.);
 +*/


 Now, my use-case started working again, well, mostly ... the next
 problem I have is the following.

 I'd like to use a server-side-toggling tree2 embedded in an pprPanelGroup:

 s:pprPanelGroup
 id=pprRoleTree
 partialTriggerPattern=.*:t[0-9]+.*
 t:tree2
 value=#{adEditRolle.roleModel}
 id=roleTree
 var=node
 varNodeToggler=t
 showRootNode=false
 preserveToggle=false
 clientSideToggle=false
 showNav=true
 showLines=true

 After triggering the first node its child nodes are shown ... fine, but
 now, even if the partialTriggerPattern matches on their commandLinks
 too, the ppr.js won't attach to them, only the already known elements
 are reattached.

 Is there a way to enhance the ppr.js in that direction?
 I think caching the patterns and their zones and reapplying them
 afterwards should do the trick, no?
 To speed up things we should only process the components received from
 the ajax call.

 Mr. Ajax, willing to do this ;-) ?

 Ciao,
 Mario

[jira] Created: (TOMAHAWK-1090) array iteration broken in partialTriggerPattern registration

[Ernst Fastl (JIRA)]

array iteration broken in partialTriggerPattern registration


 Key: TOMAHAWK-1090
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1090
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


form elements arrays are iterated instead of just the input elements while 
registering partialTriggerPatterns

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1091) Event-handlers are connected multiple times if multiple triggers match

[Ernst Fastl (JIRA)]

Event-handlers are connected multiple times if multiple triggers match
--

 Key: TOMAHAWK-1091
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1091
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


If multiple partialTriggers or patterns match for an input component, the 
event-handler advices are connected
multiple times leading to multiple refreshes. Input elements should be marked 
when event-handler advices are connected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TOMAHAWK-1089) PPRPanelGroupRenderer should obtain the encoding from the responseWriter rather than the request

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl resolved TOMAHAWK-1089.
---

Resolution: Fixed

 PPRPanelGroupRenderer should obtain the encoding from the responseWriter 
 rather than the  request
 -

 Key: TOMAHAWK-1089
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1089
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


 Encoding generally should be obtained from the response writer because it 
 avoids the need for casts

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1092) build easy to use client side API for PPR

[Ernst Fastl (JIRA)]

build easy to use client side API for PPR
-

 Key: TOMAHAWK-1092
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1092
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


Provide an easy to use javascript method for updating the content of 
pprpanelgoups and other components
which render html tags with ids like

oamPPRUpdate('id1','id2);


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1093) Build easy to use Utils for rendering ppr initialization scripts in custom components

[Ernst Fastl (JIRA)]

Build easy to use Utils for rendering ppr initialization scripts in custom 
components
-

 Key: TOMAHAWK-1093
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1093
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


build easy to use Util classes in order to enable other custom components to 
utilize the PPR architecture

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1085) AJAX requests from PPRPanelGroup ignore the Encoding type

[Ernst Fastl (JIRA)]

AJAX requests from PPRPanelGroup ignore the Encoding type
-

 Key: TOMAHAWK-1085
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1085
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


dojo.io.bind which is used by the pprPanelGroup uses the encoding set in the 
dojoConfig
since we don't yet set the encoding there the default is always used
A possible solution to this problem is getting the current encoding from the 
request
in the pprPanelGroupRenderer and set the enconding accordingly

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r566325 - /myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java

[Ernst Fastl]

Hi,

Might be an option too. I thought it best to return the client the
encoding he requests. Maybe the responseWriter-encoding
should be used before the hardcoded default.

Where does the responseWriter get the encoding from?
Is that configured?

cheers

Ernst

On 8/15/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!
  http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ppr/PPRPanelGroupRenderer.java?view=diffrev=566325r1=566324r2=566325
 
  + String encoding = UTF-8 ; // Hardcoded default
  + if(externalContext.getRequest() instanceof HttpServletRequest){
  + HttpServletRequest request = (HttpServletRequest) 
  externalContext.getRequest();
  + if(request.getCharacterEncoding() != null)
  + encoding = request.getCharacterEncoding();
  + }
 
 Hmmm  wouldn't be the correct way to do this to ask the
 ResponseWriter about the encoding?

 Something like:

 String encoding = facesContext.getResponseWriter().getCharacterEncoding();



 Ciao,
 Mario

Re: [commits] efastl commits on weekend

[Ernst Fastl]

Hi,

I just checked - the commits are definitly in the SVN. These commit
emails are auto-generated right? do I need to set something in
my SVN client for that to work?

regards

Ernst

On 7/16/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

hi,

I saw that Ernst fixed some tomahawk stuff, but I didn't see a commit email.
Was the mail-system down?

I noticed mine, on the JSF 1.2-stuff, but no other :-(

Thanks,
Matthias

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org

[jira] Created: (TOMAHAWK-1052) PPRPanelGroup does not render transient components in partial update

[Ernst Fastl (JIRA)]

PPRPanelGroup does not render transient components in partial update


 Key: TOMAHAWK-1052
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1052
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


Transient components like html in facelets templates or text in verbatim is not 
rendered
by the PPRPhaseListener in PPR responses.

This is because this components are created in the render phase, and the 
PPRPhaseListener
is invoked before that. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1053) PPRPanelGroup does not execute JavaScript which is rendered within partial responses

[Ernst Fastl (JIRA)]

PPRPanelGroup does not execute JavaScript which is rendered within partial 
responses


 Key: TOMAHAWK-1053
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1053
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


Some components render inline JavaScript . If those components are updated 
using a 
PPRPanelGroup the generated JavaScript is not executed.

One possible solution would be to parse the generated response for any 
JavaScript tags and
send this content in a separate XML tag which is then executed using the eval() 
function

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1054) JavaScript includes don't work with PPRPanelGroups

[Ernst Fastl (JIRA)]

JavaScript includes don't work with PPRPanelGroups
--

 Key: TOMAHAWK-1054
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1054
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


When components which previously had not been rendered appear additional 
JS-includes are 
not included. Somehow it would be necessary to determine those includes from 
the AddResource
in the PPRPhaseListener and send them in separate XML-elements which are then 
included
by the PPRCtrl

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

outputText_children.ftl: Expression text is undefined - if outputText value = null

[Ernst Fastl]

Hi everyone!

Cool that we use templating now. However after a recent checkout
I ran into the problem that whenever I have an output text which
has a value = null I got:

javax.servlet.jsp.JspException: Expression text is undefined on line
1, column 3 in outputText_children.ftl.


I then changed the file content of outputText_children.ftl

from ${text}
to ${text!}

(allowing missing values in freemarker)
I don't know if that is the right approach but it works for me.

shall I commit that or is there a better solution?

did I do something wrong to get this problem in the first place?

regards

Ernst

[jira] Resolved: (TOMAHAWK-1052) PPRPanelGroup does not render transient components in partial update

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl resolved TOMAHAWK-1052.
---

Resolution: Fixed

Solution:

In the PPRPanelGroupRenderer  encodeBegin method the transient attributes of 
all transient
components are set to false. further those components are marked with an 
attribute in the attributes-map.
The PPRPhaseListener checks for those markings in case of a non-PPR request and 
resets those
components to transient.

 PPRPanelGroup does not render transient components in partial update
 

 Key: TOMAHAWK-1052
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1052
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Ernst Fastl
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT


 Transient components like html in facelets templates or text in verbatim is 
 not rendered
 by the PPRPhaseListener in PPR responses.
 This is because this components are created in the render phase, and the 
 PPRPhaseListener
 is invoked before that. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TOMAHAWK-1055) After recent changes to pprPanelGroup, the full submit didn't work anymore

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl resolved TOMAHAWK-1055.
---


fixed by initially iterating over the form elements and adding the 
corresponding partial triggers for matching components

 After recent changes to pprPanelGroup, the full submit didn't work anymore
 --

 Key: TOMAHAWK-1055
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1055
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6
Reporter: Martin Marinschek
Assignee: Ernst Fastl
 Fix For: 1.1.7-SNAPSHOT


 Major overhaul to the JavaScript-system of pprPanelGroup. Comment: Currently, 
 the regexp-syntax won't work.
 steps to fix this:
  - instead of registering an event handler on every button and checking a 
 pattern-match when the event is fired, only register event-handlers for such 
 components where the pattern matches.
  - you can do this when the regexp is added to the ppr-panel-group (cause 
 then, all nodes will have been created)
  - with, this regular expressions will now also work with input-fields... 
 regards,
 Martin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TOMAHAWK-1042) The PasswordStrength component

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl updated TOMAHAWK-1042:
--

   Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
   Status: Resolved  (was: Patch Available)

thanks to Hazem Saleh for this nice new component

 The PasswordStrength component
 --

 Key: TOMAHAWK-1042
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1042
 Project: MyFaces Tomahawk
  Issue Type: New Feature
Affects Versions: 1.1.7-SNAPSHOT
Reporter: Hazem Saleh
Assignee: Ernst Fastl
Priority: Minor
 Fix For: 1.1.7-SNAPSHOT

 Attachments: PasswordStrength.patch, screenshot-1.jpg


 The passwordStrength component is needed by most of the web sites which asks 
 the user to enter a powerful password for the purpose of registeration stuff. 
 It enables its user to know the strength of the password while he is entering 
 it before even submit  the form to the server [please see the screen shot].
 Future work (soon) : 
 1. Adding custom security rules.
 2. Integration with DOJO progressbar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

suggestion: have the oam... functions in a JS include

[Ernst Fastl]

Hi!

At the moment the JavaScript function which are starting
with oam (e.g. oamSetHiddenInput, oamSubmit, ...)
are rendered at the first commandLink or commandButton.

Is there a special reason for not having those in, for instance
commons.js

The PPR JavaScript for instance uses the oamSetHiddenInput function
and therefore only works if there is at least one commandLink or button
in the page.

some users which are developing custom components would also
like to have these functions permanently available.

thoughts?

kind regards

Ernst

Re: ppr and javascript response

[Ernst Fastl]

Hi mario,

that is exactly the solution we had in mind for that problem.
Unfortunately I didn't have time to implement that so far because there
have always been more pressing issues. I hope I'll be able to do so
next week during ApacheCon.

regards

Ernst

On 4/26/07, Mario Ivankovits [EMAIL PROTECTED] wrote:

Hi!

As far as I know its not yet possible to process the javascript within
the response, is it?
Hmm ... a naive question, would it be really that easy if we just get
all script tags and eval() their content? This would not work with
referenced javascript files, but with embedded script code, no?

Ciao,
Mario

Re: PPRPhaseListener

[Ernst Fastl]

Hi,

The PPRPhaseListener is called before RenderResponse so in my understanding
decode should have been called normally on all components.

The only thing
ommited is the normal rendering. Rather the PPRPhaseListener seeks the
affected components based on their clientIds calls the encodeMethods, packs
the output  into XML, sends this to the client and quits the Lifecycle
afterwards.

I would guess if there is a problem with the alias-bean it is probably
caused by
not rendering it. Would that be possible ?

regards

Ernst

On 4/25/07, Volker Weber [EMAIL PROTECTED] wrote:

Hi,

i don't know how the PPRPhaseListener works, but i think the problem
with the aliasBean is the same as with updateing a component inside of
a UIData.
In the TobagoLifecycle we climb up the viewTree from the
'affectedAjaxComponent' (we should rename this parameter) to search
for a UIData and invoke decode on this, if found.
Should be easy to implement something like this in the
PPRPhaseListener for aliasScope,
a bit more complicated for aliasBean.


Regards,
Volker

2007/4/25, Ernst Fastl [EMAIL PROTECTED]:
 Thaks for the info,

 following stuff is missing:

 -JavaDoc - I'll write that together with the bugfix of
 https://issues.apache.org/jira/browse/TOMAHAWK-969

 -testing with RI - hopefully I'll also find time for this

 -testcase - how would junit test an AJAX component?

 regarding the issue with the alias-been I would guess that is caused
 by the fact that this part of the page is not rendered - cannot think
 of a quick solution for that one - any ideas?

 regards

 Ernst

 On 4/25/07, Gerald Müllan [EMAIL PROTECTED] wrote:
  Hi,
 
  you can take a look at the promotion requirements in the wiki:
 
  http://wiki.apache.org/myfaces/promotion
 
  One other issue i have observed; Using ppr in combination with an
  aliasBean causes the component to fail the variable lookup. This is
  because of scoping of the alias.
 
  So, using ppr with alias bean variables does not work. I actually had
  no time to take a deeper look into this, but i wouldn`t say this is
  kind of a blocker issue for promotion to tomahawk.
 
  cheers,
 
  Gerald
 
  On 4/25/07, Ernst Fastl [EMAIL PROTECTED] wrote:
   There is one issue I'd like to sort out before that:
  
   https://issues.apache.org/jira/browse/TOMAHAWK-969
  
   I hope I'll find time to do that on the weekend or next week during the 
con.
  
   other than that since I'm using the PPRPanelGroup sucessfully in 2
   projects for 8 months now I have the feeling it is ready for promotion.
   Where can the general requirements for graduation be found?
  
  
   On 4/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Why not.
   
Ernst, do you think it is stable ?
Are all requirements fulfilled for a possible graduation of that 
component ?
   
-Matthias
   
On 4/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
 What do you guys think the chances are of moving this into the next 
Tomahawk
 release?


 On 4/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  Is there any reason for not making it part of the AJAX api ?
 
  The AjaxDecodePhaseListener is also part of the package
  org.apache.myfaces.custom.ajax.api
 
  One more, can we make the package named
 
  org.apache.myfaces.ajax.api
 
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



 --
 Dennis Byrne
   
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
 
 
  --
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 

Re: PPRPhaseListener

[Ernst Fastl]

Shure see you there soon, I'm confident that we'll be able to find a solution.

greez

Ernst

On 4/26/07, Gerald Müllan [EMAIL PROTECTED] wrote:

Well, i had a quick look with a dataTable where the value corresponds
to a aliasBean alias which references a list of objects.

In the PPRPhaseListener the dataTable has been seeked correctly (and
the main tags rendered out), but during rendering its children the
amount is 0.

I believe it is the same problem we had with f:loadBundle, which does
its job only when rendering happens and not in all phases of the
lifecycle. This results in not rendering the outputText mapped to the
value of the bundle.

Martin developed s:loadBundle, which is available in all lifecylce
phases and addresses this problem.

It seems that it takes more time to step into the alias-bean issue.
Ernst, maybe we get some minutes during apacheCon.

cheers,

Gerald

On 4/26/07, Ernst Fastl [EMAIL PROTECTED] wrote:
 Hi,

 The PPRPhaseListener is called before RenderResponse so in my understanding
 decode should have been called normally on all components.

 The only thing
 ommited is the normal rendering. Rather the PPRPhaseListener seeks the
 affected components based on their clientIds calls the encodeMethods, packs
 the output  into XML, sends this to the client and quits the Lifecycle
 afterwards.

 I would guess if there is a problem with the alias-bean it is probably
 caused by
 not rendering it. Would that be possible ?

 regards

 Ernst

 On 4/25/07, Volker Weber [EMAIL PROTECTED] wrote:
  Hi,
 
  i don't know how the PPRPhaseListener works, but i think the problem
  with the aliasBean is the same as with updateing a component inside of
  a UIData.
  In the TobagoLifecycle we climb up the viewTree from the
  'affectedAjaxComponent' (we should rename this parameter) to search
  for a UIData and invoke decode on this, if found.
  Should be easy to implement something like this in the
  PPRPhaseListener for aliasScope,
  a bit more complicated for aliasBean.
 
 
  Regards,
  Volker
 
  2007/4/25, Ernst Fastl [EMAIL PROTECTED]:
   Thaks for the info,
  
   following stuff is missing:
  
   -JavaDoc - I'll write that together with the bugfix of
   https://issues.apache.org/jira/browse/TOMAHAWK-969
  
   -testing with RI - hopefully I'll also find time for this
  
   -testcase - how would junit test an AJAX component?
  
   regarding the issue with the alias-been I would guess that is caused
   by the fact that this part of the page is not rendered - cannot think
   of a quick solution for that one - any ideas?
  
   regards
  
   Ernst
  
   On 4/25/07, Gerald Müllan [EMAIL PROTECTED] wrote:
Hi,
   
you can take a look at the promotion requirements in the wiki:
   
http://wiki.apache.org/myfaces/promotion
   
One other issue i have observed; Using ppr in combination with an
aliasBean causes the component to fail the variable lookup. This is
because of scoping of the alias.
   
So, using ppr with alias bean variables does not work. I actually had
no time to take a deeper look into this, but i wouldn`t say this is
kind of a blocker issue for promotion to tomahawk.
   
cheers,
   
Gerald
   
On 4/25/07, Ernst Fastl [EMAIL PROTECTED] wrote:
 There is one issue I'd like to sort out before that:

 https://issues.apache.org/jira/browse/TOMAHAWK-969

 I hope I'll find time to do that on the weekend or next week during 
the con.

 other than that since I'm using the PPRPanelGroup sucessfully in 2
 projects for 8 months now I have the feeling it is ready for 
promotion.
 Where can the general requirements for graduation be found?


 On 4/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Why not.
 
  Ernst, do you think it is stable ?
  Are all requirements fulfilled for a possible graduation of that 
component ?
 
  -Matthias
 
  On 4/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
   What do you guys think the chances are of moving this into the 
next Tomahawk
   release?
  
  
   On 4/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
Is there any reason for not making it part of the AJAX api ?
   
The AjaxDecodePhaseListener is also part of the package
org.apache.myfaces.custom.ajax.api
   
One more, can we make the package named
   
org.apache.myfaces.ajax.api
   
   
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
  
  
   --
   Dennis Byrne
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 

   
   
--
http://www.irian.at
   
Your JSF

Re: PPRPhaseListener

[Ernst Fastl]

Thaks for the info,

following stuff is missing:

-JavaDoc - I'll write that together with the bugfix of
https://issues.apache.org/jira/browse/TOMAHAWK-969

-testing with RI - hopefully I'll also find time for this

-testcase - how would junit test an AJAX component?

regarding the issue with the alias-been I would guess that is caused
by the fact that this part of the page is not rendered - cannot think
of a quick solution for that one - any ideas?

regards

Ernst

On 4/25/07, Gerald Müllan [EMAIL PROTECTED] wrote:

Hi,

you can take a look at the promotion requirements in the wiki:

http://wiki.apache.org/myfaces/promotion

One other issue i have observed; Using ppr in combination with an
aliasBean causes the component to fail the variable lookup. This is
because of scoping of the alias.

So, using ppr with alias bean variables does not work. I actually had
no time to take a deeper look into this, but i wouldn`t say this is
kind of a blocker issue for promotion to tomahawk.

cheers,

Gerald

On 4/25/07, Ernst Fastl [EMAIL PROTECTED] wrote:
 There is one issue I'd like to sort out before that:

 https://issues.apache.org/jira/browse/TOMAHAWK-969

 I hope I'll find time to do that on the weekend or next week during the con.

 other than that since I'm using the PPRPanelGroup sucessfully in 2
 projects for 8 months now I have the feeling it is ready for promotion.
 Where can the general requirements for graduation be found?


 On 4/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Why not.
 
  Ernst, do you think it is stable ?
  Are all requirements fulfilled for a possible graduation of that component ?
 
  -Matthias
 
  On 4/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
   What do you guys think the chances are of moving this into the next 
Tomahawk
   release?
  
  
   On 4/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
Is there any reason for not making it part of the AJAX api ?
   
The AjaxDecodePhaseListener is also part of the package
org.apache.myfaces.custom.ajax.api
   
One more, can we make the package named
   
org.apache.myfaces.ajax.api
   
   
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
  
  
   --
   Dennis Byrne
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



--
http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Created: (TOMAHAWK-969) Partial Refresh does not work if triggerButton comes after the last PPRPanelGroup

[Ernst Fastl (JIRA)]

Partial Refresh does not work if triggerButton comes after the last 
PPRPanelGroup
-

 Key: TOMAHAWK-969
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-969
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.6-SNAPSHOT


If a PPRPanelGroup triggers on a button which is rendered after the 
PPRPanelGroup the partial refresh does not work.
This is caused by the fact, that the PanelGroup renders the Javascript which 
replaces the button onClick-Handler 
directly after the panelGroup. This can probably be resolved by packing the JS 
in a anonymous function
and register that with dojo.addOnLoad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: PPRPhaseListener

[Ernst Fastl]

There is one issue I'd like to sort out before that:

https://issues.apache.org/jira/browse/TOMAHAWK-969

I hope I'll find time to do that on the weekend or next week during the con.

other than that since I'm using the PPRPanelGroup sucessfully in 2
projects for 8 months now I have the feeling it is ready for promotion.
Where can the general requirements for graduation be found?


On 4/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

Why not.

Ernst, do you think it is stable ?
Are all requirements fulfilled for a possible graduation of that component ?

-Matthias

On 4/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
 What do you guys think the chances are of moving this into the next Tomahawk
 release?


 On 4/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  Is there any reason for not making it part of the AJAX api ?
 
  The AjaxDecodePhaseListener is also part of the package
  org.apache.myfaces.custom.ajax.api
 
  One more, can we make the package named
 
  org.apache.myfaces.ajax.api
 
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



 --
 Dennis Byrne


--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

[jira] Created: (TOMAHAWK-966) PPR examples containing commandLinks produce javascript errors in clientSide validation

[Ernst Fastl (JIRA)]

PPR examples containing commandLinks produce javascript errors in clientSide 
validation
---

 Key: TOMAHAWK-966
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-966
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.6-SNAPSHOT


all PPR examples which contain commandLinks produce Javascript errors instead 
of submitting
when the links are clicked. Seems to be related to the client Side validation 
JS.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TOMAHAWK-966) PPR examples containing commandLinks produce javascript errors in clientSide validation

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl updated TOMAHAWK-966:
-

Status: Patch Available  (was: Open)

 PPR examples containing commandLinks produce javascript errors in clientSide 
 validation
 ---

 Key: TOMAHAWK-966
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-966
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Assigned To: Cagatay Civici
 Fix For: 1.1.6-SNAPSHOT

 Attachments: tomahawk-966- ppr.patch


 all PPR examples which contain commandLinks produce Javascript errors instead 
 of submitting
 when the links are clicked. Seems to be related to the client Side validation 
 JS.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: pprPanelGroup

[Ernst Fastl]

Hi,

The PPR update is asynchronous, so it should not matter if the Dialog
pops up before or after the update. At least this is the way it works for me.

regards

Ernst

On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

ok, lemme check the dojo behind ;)

On 3/30/07, Gerald Müllan [EMAIL PROTECTED] wrote:
 No :)

 On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  yeah !
 
  volunteering ?
 
  On 3/30/07, Gerald Müllan [EMAIL PROTECTED] wrote:
   Sounds like we need a new attribute for a js callback after returning
   from ppr request.
  
   On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
   
I need to show the modalDialog
(onclick=dojoDialog.show();)
   
AFTER the pprRequest has been executed
   
any idea ?
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
  
   --
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 


 --
 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: pprPanelGroup

[Ernst Fastl]

Then wrap whatever u use this value-binding for with a
pprPanelGroup with partialTriggers=detaisLink or the
clientId if it is elsewhere.

On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

   h:commandLink id=detailsLink  onclick=dojoDialog.show();
 t:updateActionListener
property=#{table.detailCustomer} value=#{customer} /
 h:outputText value=view details /
   /h:commandLink



and presenting this inside the modalDialog...

value=#{detailCustomer.firstname}

.M

On 3/30/07, Ernst Fastl [EMAIL PROTECTED] wrote:
 Hi,

 The PPR update is asynchronous, so it should not matter if the Dialog
 pops up before or after the update. At least this is the way it works for me.

 regards

 Ernst

 On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  ok, lemme check the dojo behind ;)
 
  On 3/30/07, Gerald Müllan [EMAIL PROTECTED] wrote:
   No :)
  
   On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
yeah !
   
volunteering ?
   
On 3/30/07, Gerald Müllan [EMAIL PROTECTED] wrote:
 Sounds like we need a new attribute for a js callback after returning
 from ppr request.

 On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi,
 
  I need to show the modalDialog
  (onclick=dojoDialog.show();)
 
  AFTER the pprRequest has been executed
 
  any idea ?
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 


 --
 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

   
   
--
Matthias Wessendorf
http://tinyurl.com/fmywh
   
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
   
  
  
   --
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: javascript usage

[Ernst Fastl]

you probably mean

typeof foo == undefined

vs

foo === undefined

but to be honest I was never really sure what the difference is.
If the latter is the better approach u can go ahead and replace
the statements, or I'll do it in the next patch.

regards

Ernst

On 3/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

Hello,

looking at some JS pieces in PPR I am seeing lot's of

foo == undefined

that isn't really working in some cases...

foo === undefined
(or foo !== undefined)

would be better.

Any thoughts ?

--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: java.lang.String.contains (java.lang.String) should be removed [Was: svn commit: r523853]

[Ernst Fastl]

sorry for that guys, and thanks for the hint, I'll use a 1.4 JDK the next time
I create a patch

On 3/30/07, Gerald Müllan [EMAIL PROTECTED] wrote:

Thanks Mike for the advice and the quick fix.

Looks good to me,

cheers,

Gerald

On 3/30/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
 Never mind.  I figured out a quick fix, but you might want to
 double-check my work.

 On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
  Looks like you failed to try compiling it under Java 1.4.2.  A 1.5-ism
  is committed to the code.
 
  
E:\workspaces\myfaces\myfaces-2007-03-29-1000\tomahawk\sandbox\examples\src\main
  \java\org\apache\myfaces\examples\ppr\PPRExampleBean.java:[74,29] cannot 
resolve
   symbol
  symbol  : method contains (java.lang.String)
  location: class java.lang.String
 
  On 3/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Author: gmuellan
   Date: Thu Mar 29 15:23:42 2007
   New Revision: 523853
  
   URL: http://svn.apache.org/viewvc?view=revrev=523853
   Log:
   applied patch https://issues.apache.org/jira/browse/TOMAHAWK-945, Thx to 
Ernst Fastl
  
   Added:
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupCommandLink.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupDataScroller.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupLoadingMessage.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupMultiple.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupOnChange.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupPartialTriggerPattern.jsp
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroupPartialTriggers.jsp
   Removed:
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/pprPanelGroup.jsp
   Modified:
   
myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/ppr/resource/ppr.js
   
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/ppr/PPRExampleBean.java
   myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/home.jsp
  
   Modified: 
myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/ppr/resource/ppr.js
   URL: 
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/ppr/resource/ppr.js?view=diffrev=523853r1=523852r2=523853
   
==
   --- 
myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/ppr/resource/ppr.js
 (original)
   +++ 
myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/ppr/resource/ppr.js
 Thu Mar 29 15:23:42 2007
   @@ -210,12 +210,12 @@
}
else
{
   -this.form.submit_orig();
   +this.form.submit_orig(triggerElement);
}
}
else
{
   -this.form.submit_orig();
   +this.form.submit_orig(triggerElement);
}
}
  
  
   Modified: 
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/ppr/PPRExampleBean.java
   URL: 
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/ppr/PPRExampleBean.java?view=diffrev=523853r1=523852r2=523853
   
==
   --- 
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/ppr/PPRExampleBean.java
 (original)
   +++ 
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/ppr/PPRExampleBean.java
 Thu Mar 29 15:23:42 2007
   @@ -22,8 +22,9 @@
import org.apache.myfaces.examples.inputSuggestAjax.Address;
  
import javax.faces.event.ValueChangeEvent;
   -import java.util.List;
import java.util.ArrayList;
   +import java.util.Iterator;
   +import java.util.List;
  
/**
 * @author Ernst Fastl
   @@ -31,14 +32,26 @@
public class PPRExampleBean
{
private String _textField;
   -
   +
private String _message;
   -
   -private Boolean _partialUpdateConfiguredButton;
   -
   -private Boolean _partialChangeCheckBox=Boolean.FALSE;
   -
   -private String _partialChangeDropDown;
   +
   +private Boolean _checkBoxValue =Boolean.FALSE;
   +
   +private String _dropDownValue;
   +
   +private List _names;
   +
   +public List getNames()
   +{
   +if(_names == null)
   +_names = getListMasterData();
   +return _names;
   +}
   +
   +public void setNames(List names)
   +{
   +_names = names;
   +}
  
public String getTextField()
{
   @@ -50,29 +63,31 @@
this._textField = textField;
}
  
   -   public Boolean getPartialUpdateConfiguredButton() {
   -   return

[jira] Commented: (TOMAHAWK-945) Split the PPR Example into smaller easy to understand Examples with explanations

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485546
 ] 

Ernst Fastl commented on TOMAHAWK-945:
--

Good idea, I wouldn't have liked that as well. thanks Jeff

 Split the PPR Example into smaller easy to understand Examples with 
 explanations
 

 Key: TOMAHAWK-945
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-945
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Assigned To: Gerald Müllan
 Fix For: 1.1.6-SNAPSHOT

 Attachments: tomahawk-945- ppr examples.patch


 A lot of users have been complaining, that the sandbox PPR example is 
 difficult to understand and they
 did't get it working. Therefore it would be good to split this example into a 
 number of different
 examples for the different features similar to the datatable examples

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TOMAHAWK-945) Split the PPR Example into smaller easy to understand Examples with explanations

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl updated TOMAHAWK-945:
-

Status: Patch Available  (was: Open)

 Split the PPR Example into smaller easy to understand Examples with 
 explanations
 

 Key: TOMAHAWK-945
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-945
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.6-SNAPSHOT

 Attachments: tomahawk-945- ppr examples.patch


 A lot of users have been complaining, that the sandbox PPR example is 
 difficult to understand and they
 did't get it working. Therefore it would be good to split this example into a 
 number of different
 examples for the different features similar to the datatable examples

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

renderMessages in common.js produces root - object has no properties JS error

[Ernst Fastl]

Hi!

I just split the PPR example into few simpler, easier to understand examples.
see TOMAHAWK-945 patch

While doing so I noticed, that the commandLinks in the examples won't submit
in firefox (haven't tried other browsers so far). In the file common.js the
renderMessages function gets called with null as component and produces a
JS-Error object has no properties.

Could this be related to client-side validation?

If so, did I do anything wrong with the commandLinks in the examples?

thanks in advance

Ernst

[jira] Created: (TOMAHAWK-945) Split the PPR Example into smaller easy to understand Examples with explanations

[Ernst Fastl (JIRA)]

Split the PPR Example into smaller easy to understand Examples with explanations


 Key: TOMAHAWK-945
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-945
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.6-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.6-SNAPSHOT


A lot of users have been complaining, that the sandbox PPR example is difficult 
to understand and they
did't get it working. Therefore it would be good to split this example into a 
number of different
examples for the different features similar to the datatable examples

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-909) PPRPanelGroup ignores return value of false from custom onClick

[Ernst Fastl (JIRA)]

PPRPanelGroup ignores return value of false from custom onClick 


 Key: TOMAHAWK-909
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-909
 Project: MyFaces Tomahawk
  Issue Type: Bug
Reporter: Ernst Fastl




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TOMAHAWK-909) PPRPanelGroup ignores return value of false from custom onClick

[Ernst Fastl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernst Fastl updated TOMAHAWK-909:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup ignores return value of false from custom onClick 
 

 Key: TOMAHAWK-909
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-909
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.5-SNAPSHOT

 Attachments: tomahawk-909.patch


 PPRPanelGroup ignores return value of false from custom onClick 
 this proved to be a problem when combining a cliend Side tabbedPane with a 
 PPRPanelGroup

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MyFaces Documentation

[Ernst Fastl]

Hi,

a good starting point is always the myfaces wiki

http://wiki.apache.org/myfaces/

examples can be found at

http://www.irian.at/myfaces.jsf

scrolling a little down searching for MyFaces Examples you
will find links to the online examples which also
show the source code.

hope that helps

regards

Ernst

On 2/21/07, Oscar Duque [EMAIL PROTECTED] wrote:


Greetings to all,

Please can you tell me where can i found development guides, tutorial and
the examples, in order to introduce me in MyFaces WORLD ?

Thanks in advance, and go ahead OPEN COMMUNITY ...

Oscar Duque

Express yourself instantly with MSN Messenger! MSN Messenger Download today
it's FREE!

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl]

Hi again,

Thank you very much for your opinions and insights. I understand now that there
are doubts supporting such a feature. What I understood these are mainly
about encouraging users to use not best practise approaches. IMO this
is for sure a duty of teachers or books, but a webdevelopment framework?
I'm not so sure about that. I think users should be provided with as much
flexibility as possible rather than trying to force them to share all
our philosophy.

And also this is as martin and mattias pointed out usable in small
scale applications
tiny prototypes and so on. Seeing competitions as ruby on rails and php
features like that could make JSF also more attractive for prototyping.

But thats just my opinion and I'm for sure not starting to do something
not approved by the community again.

So what is the desicion?

1.) Seperate NavigationHandlerImpl

2.) Configurable Option

3.) Custom NH code in the wiki with a discouraged note

4.) Not at all

regards

Ernst

On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

I am really fine with adding this NH_Impl to Tomahawk.
Here are my rules for that:
-It is not used by default!
-it is not configured to a bogus web.xml context param
-it should be used in the app's faces-cfg.xml file

the cons and pros are like
Do you like Rails, or not :)

Well, somethimes that makes sense; sometimes not.

The fun is, that you can choose! Just put it to your faces-cfg.
I have heard that requirement before that thread. I don't think it's
a not understanding
JSF thing. Sorta lazy guy approach ...

-M

On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote:


 On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote:

  In reality there is a dependency between two pages, there is a silent
  contract how to prepare the managed beans so that the destination page
  knows what to display (and I think the f:param stuff is useless here).
  So more often than not you'll use a updateActionListener to set stuff on
  the destination backing bean. And voilla, you'll have hard dependency
  between these two pages.

 This is an important point, no matter how you architect your navigation.

 shameless-plug
 That is why Shale's view controller has a prerender() method ... you are
 encouraged to use that method in the destination page to pull data that
 this page needs out of the model, rather than having the origin page push
 data into the destination page (or some request scoped objects whose names
 are known to both).  That way, coupling is minimized to something like
 passing primary keys -- and I like the convention of always passing, say, a
 customerId, in the same place throughout the application (independent of
 particular pages), to minimize direct coupling between any two particular
 pages.

 This approach also makes it *much* easier for your application to support
 bookmarkable GET URLs that pass primary keys with request parameters.
 /shameless-plug

 Craig




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

[jira] Created: (TOMAHAWK-760) modalDialog shows in page instead of being a popup in Internet Explorer

[Ernst Fastl (JIRA)]

modalDialog shows in page instead of being a popup in Internet Explorer
---

 Key: TOMAHAWK-760
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-760
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
 Fix For: 1.1.5-SNAPSHOT


modalDialog shows in page instead of being a popup in Internet Explorer since 
the lates changes in the DojoUtils stuff
I couldn't figure out why this doesn't work anymore so far but it could be 
related to ressource loading
since the page seems to try to load something for a rather long time

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl]

Hmm, sounds interesting, what exactly would you have in mind,
something like a Callback for additional security checks which receives
the viewId and then can check wheather or not access is allowed and
return a boolean or so?

On 10/30/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl

for accessing navigation cases. It is important in security cases to
*check* navigation cases ...

so your impl could benefit from that !

On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote:
 You're right, an alternate NavigationHandler shipped with MyFaces
 is probably the better choice let's go with that approach.

 thanks for your ideas

 On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
2) since in JSF 1.1 navigation outcomes are string it is completely 
possible
for a programmer to have a syntax error in out comes
  
   Sorry don't get your point here, if an action returns a misspelled outcome
   or a misspelled viewId you would not want to navigate in both cases right?
 
  I think he means the 404 error, ...
 
 
  However, I kinda like stuff like that, but not configurable!
  We had had enough fun with bogus features like dummyForm.
 
  We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
  sb. really really
  want that, use that particular NH.
 
  just my $0.02
 
  -M
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

[jira] Created: (TOMAHAWK-758) Enable traditional submit for exceptions during partial update to show error pages

[Ernst Fastl (JIRA)]

Enable traditional submit for exceptions during partial update to show error 
pages
--

 Key: TOMAHAWK-758
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-758
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


Default behaviour if an exception occurs during a partial update 
for instance if the http-session is timed out or the server is down
to show a javascript alert box with an ajax error that doesn't help much.
It would make sense to do a normal submit then to get a proper 404-page
or display a proper error-page

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-758) Enable traditional submit for exceptions during partial update to show error pages

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-758?page=all ]

Ernst Fastl updated TOMAHAWK-758:
-

Status: Patch Available  (was: Open)

 Enable traditional submit for exceptions during partial update to show error 
 pages
 --

 Key: TOMAHAWK-758
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-758
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: ppr - tomahawk 758.patch


 Default behaviour if an exception occurs during a partial update 
 for instance if the http-session is timed out or the server is down
 to show a javascript alert box with an ajax error that doesn't help much.
 It would make sense to do a normal submit then to get a proper 404-page
 or display a proper error-page

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: calling authors

[Ernst Fastl]

Putting the article in the wiki sounds like a good idea to me. Everybody
would have the possiblility of adding information and we would hopefully
also have a nice collection of information for new users.

btw. I'd also be interested in writing

regards

Ernst

On 10/26/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:

another idea comes into my mind, when I finished the article I can put it on
wiki or post it to list, and let others edit it or send their suggestions.


On 10/26/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
 me 2
 I am also volunteer

 I don't have any experience using Tobago. I haven't used Shale in any real
world project.
 but I have used the rest of component and some times applied some small
changes in them.
 tell me what do you want in that article?
 what topics should be covered in what detail.




 On 10/26/06, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  I am writing one on Trinidad for the German Java Magazine,
  maybe we can translate it later (deadline is december 20th or so)
 
  (I know I need to send you the portlet article too :) )
 
  -M
 
  On 10/25/06, Kito D. Mann  [EMAIL PROTECTED]  wrote:
   Hello,
  
   I'm currently looking for people who are interested in writing great
   articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or
   Shale. If you're interested, please reply!
  
  
~~~
   Kito D. Mann ([EMAIL PROTECTED] )
   Author, JavaServer Faces in Action
   http://www.virtua.com http://www.virtua.com/  - JSF/Java EE
consulting,
   training, and mentoring
   http://www.JSFCentral.com http://www.jsfcentral.com/  - JavaServer
Faces
   FAQ, news, and info
  
  
  
  
  
 
 
  --
  Matthias Wessendorf
  http://tinyurl.com/fmywh
 
  further stuff:
  blog: http://jroller.com/page/mwessendorf
  mail: mwessendorf-at-gmail-dot-com
 



 --
 Arash Rajaeeyan



--
Arash Rajaeeyan

Re: [OT] Google Code Search

[Ernst Fastl]

Cool stuff,

there is also a similar new  serachengine

http://www.krugle.com/

where you can search for code and projects


On 10/26/06, Kito D. Mann [EMAIL PROTECTED] wrote:

One of the coolest things I noticed in my vanity search was that it looks
inside zip files:
http://www.google.com/codesearch?hl=enlr=q=kito+mannbtnG=Search

Note the code from my book located in a zip file on the Manning web site...

~~~
Kito D. Mann ([EMAIL PROTECTED])
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info


 -Original Message-
 From: Sean Schofield [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 24, 2006 2:34 PM
 To: MyFaces Development; dev@shale.apache.org
 Subject: [OT] Google Code Search

 I just found out about this[1].  You can now search public
 SVN and CVS repositories.  Pretty cool.

 Sean

 [1]http://www.google.com/codesearch

Re: Component and tags documentation and wiki

[Ernst Fastl]

great idea,

maybe we could put the examples right after or before the screen shots
I have the impression, that many users like to first see an example
and then read additional information

regards

Ernst

On 10/27/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:

Hello All,
I want to synchronize the latest web site documentations and Wiki
Information
I want to use the following headers and clean the wiki information
I hope if the quality of works was good, the result transferred to web site
documentations to.
I want to use following headers and mote information into them and complete
the definition:

[Component Name]
Description
Screen Shot
API
Usage
Syntax
Configuration
Instructions
Additional Information
Examples
FAQ
Known Bugs


first: does any one has any objections?
second: do you suggest another format?
Arash Rajaeeyan

Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl]

Hi!

At the moment when no navigation case for an outcome is found
the navigationHandler decides to stay at the same view. I think
an option for web.xml would be useful to tell the navigationHandler
if no navigation case for an outcome is found, but the outcome
matches a viewId to navigate to this view id.

This idea was mainly driven by a lot of jsf-projects where I saw for each
view id:

navigation-rule
   from-view-id*/from-view-id
   navigation-case
   from-outcomeviewId/from-outcome
   to-view-id/viewId.xhtml/to-view-id
   redirect/
   /navigation-case
...


which seems kind of unnecessary to me

what do you think about that?

regards

Ernst

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl]

1) it is against the spec behaviour


Of course you are absolutely right with this
therefore I'd make it an optional feature, being able to turn it on with a
configuration parameters


2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a programmer to have a syntax error in out comes


Sorry don't get your point here, if an action returns a misspelled outcome
or a misspelled viewId you would not want to navigate in both cases right?


3) this make confusion between page names and outcomes (navigation events)


Confusion is exactly the point, what I get told as the main reason not
to choose
JSF by many users considering it is:
It is to complex for me I have to write all those xml-files to get
just Hello world running
That would be a way for them with one configuration file less.


4) I think outcomes and names of JSF pages should stay separate.
JSF navigation is like an finite state machine (FSM) or finite state
automaton, states are pages and outcomes are input to the automaton, this
keeps modeling UI very simple.
and also it makes it possible for formal verification of JSF application,
with available tools.


Good point. But again, no one would be forced to use the feature, I'd
say it's for starters and lazy programmers, the others can leave it
turned off.

All together, I see your points, but I don't understand
what harm could be caused by an optional feature?




On 10/30/06, Ernst Fastl [EMAIL PROTECTED] wrote:
 Hi!

 At the moment when no navigation case for an outcome is found
 the navigationHandler decides to stay at the same view. I think
 an option for web.xml would be useful to tell the navigationHandler
 if no navigation case for an outcome is found, but the outcome
 matches a viewId to navigate to this view id.

 This idea was mainly driven by a lot of jsf-projects where I saw for each
 view id:

 navigation-rule
 from-view-id*/from-view-id
 navigation-case
 from-outcomeviewId/from-outcome
 to-view-id/viewId.xhtml/to-view-id
 redirect/
 /navigation-case
 ...


 which seems kind of unnecessary to me

 what do you think about that?

 regards

 Ernst

Re: Option for NavigationHandler to support viewIds as outcome

[Ernst Fastl]

You're right, an alternate NavigationHandler shipped with MyFaces
is probably the better choice let's go with that approach.

thanks for your ideas

On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

  2) since in JSF 1.1 navigation outcomes are string it is completely possible
  for a programmer to have a syntax error in out comes

 Sorry don't get your point here, if an action returns a misspelled outcome
 or a misspelled viewId you would not want to navigate in both cases right?

I think he means the 404 error, ...


However, I kinda like stuff like that, but not configurable!
We had had enough fun with bogus features like dummyForm.

We can provide a LazyNavigationHandlerImpl for that in Tomahawk and if
sb. really really
want that, use that particular NH.

just my $0.02

-M


--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

[jira] Created: (MYFACES-1482) alternate NavigationHandler to support viewIds as outcome

[Ernst Fastl (JIRA)]

alternate NavigationHandler to support viewIds as outcome
-

 Key: MYFACES-1482
 URL: http://issues.apache.org/jira/browse/MYFACES-1482
 Project: MyFaces Core
  Issue Type: New Feature
  Components: General
Affects Versions: 1.1.4
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


Provide an alternative NavigationHandler Implementation that checks if an 
outcome
for which no navigation Case could be identifiied matches a viewId and navigates
to that viewId

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: how do we handle old taglib definitions in the sandbox

[Ernst Fastl]

On one hand it is right that components of the sandbox are potential subjects
for change, but would it really hurt to do a slower deprecation? Like Werner
pointed out, some people are already using sandbox components in their
production environments although this may never have been recommended
they do it. So I think a slower transition with some kind of deprecation
mechanism would be appropriate wouldn't it?

On 10/13/06, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote:

Isn't that the risk of using components of the sandbox? IMHO, sandbox
components should always be subject to change without notice. If they
are promoted to 'production quality', then so much the better.

Therefore, my personal preference would be to remove all references in
the sandbox after the promotion. I think -correct me if I'm wrong- that
the same was done for the schedule component, which was the last to be
moved from sandbox to tomahawk.

It is easy enough to change the namespace in the jsp's after an upgrade
(global search and replace) and -as I said- everyone should know that
sandbox components are used at your own risk.



-Oorspronkelijk bericht-
Van: news [mailto:[EMAIL PROTECTED] Namens Werner Punz
Verzonden: donderdag 12 oktober 2006 23:19
Aan: dev@myfaces.apache.org
Onderwerp: how do we handle old taglib definitions in the sandbox


Now that I am finally moving the first dojo component out I have one
last remaining structural problem, how do we handle the taglib issue. As
far as I can see, once I move a component from the sandbox to
tomahawk I will break the namespace.

Not that I mind a clear cut on this issue, but some users already have
started to use the sandbox components. Now theoretically it should be
possible to leave the tld defs in the
sandbox while the code is moved upwards.
for the time being, with a slow deprecation of the affected entries over

time.

How are we going to handle this issue.

I need a good answer here so that I finally can set the dojo migration
to resolved.


Disclaimer:
This message contains information that may be privileged or confidential and is 
the property of Sogeti Nederland B.V. or its Group members. It is intended only 
for the person to whom it is addressed. If you are not the intended recipient, 
you are not authorized to read, print, retain, copy, disseminate, distribute, 
or use this message or any part thereof. If you receive this message in error, 
please notify the sender immediately and delete all copies of this message.

Re: how do we handle old taglib definitions in the sandbox

[Ernst Fastl]

I agree ,If deprecation is not really possible ( for now I could also
not think of
a appropriate way to do so) then the clear cut has to be done sooner or
later anyway. And as erik-berndt already pointed out, the migration
for the users will be just a text-replace in their jsps or facelet-xhtml files.
Before upgrading users should read the release notes anyway :-)

On 10/13/06, Werner Punz [EMAIL PROTECTED] wrote:

Ernst Fastl schrieb:
 On one hand it is right that components of the sandbox are potential
 subjects
 for change, but would it really hurt to do a slower deprecation? Like
 Werner
 pointed out, some people are already using sandbox components in their
 production environments although this may never have been recommended
 they do it. So I think a slower transition with some kind of deprecation
 mechanism would be appropriate wouldn't it?

The problem is, there is no deprecation mechanism...
I asked what the consensous is here, regarding this problem,
but I think a clear cut has to do it for now...
At least in my case, the dojoInitializer, this is non critical, not
too many users use it, we might have to go a different route
for the high level end user components, I guess.

But keeping the tld codebase twice is a huge burden.

Re: Select One Row with Image

[Ernst Fastl]

Hi Manmeet!

You could either write a new component similar to the SelectOneRow.
It would probably have two additional attributes like image and
selectedImage which renders an input type image.

or you could just use a normal  image inide a commandLink.
The commandLink would then probably also contain
updateActionListener which sets a Boolean Property in the
iterated Objects (= the one you access with the name
specified in the var attribute of the datatable). The graphic image
could than have a attribute like:
url=#{var.selected ? 'img/selected.jpg' : 'img/not_selected.jpg'}

hope this helps

regards

Ernst

On 10/9/06, manmeet [EMAIL PROTECTED] wrote:


Hi all,

I am using the sandbox component for select one row.
Works perfectly fine.

But now what I want to do is use an image to select a row from a datatable
instead of radio buttons created by the selectOneRow component.
The radio button needs to be replaced by an image which when selected flips
to a different image which indicating selected row.

PLease let me know how can this be done? I am a newbie to Myfaces so any
help shall be appreciated.

Thanks to all.

-Manmeet
--
View this message in context: 
http://www.nabble.com/Select-One-Row-with-Image-tf2413162.html#a6726642
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: Enhancing Partial Page Rendering

[Ernst Fastl]

Hi Björn!

Customizing validation is for sure an interesting topic. In the meantime
you may be able to solve your problem if you set the parent selector to
immediate and attach a valueChangListener which changes the
data for the second one in the backing bean.

You could also use the ajax-enabled combo box which you can see in
the current tomahawk-sandbox examples.
(I think thats probably easier)

If the problem is more complex you could also use subForms to limit
validation to certain components on your page.

hope that helps a little

thanks for your feedback

regards

Ernst

On 9/28/06, Björn Voß [EMAIL PROTECTED] wrote:

Hi Ernst

your enhancement looks really great.
I'm currently using ajax4jsf to ajaxing my jsf-pages, but I would like to have 
it done all in tomahawk. :-)

I have one additional suggestion:
Disable validation or customize what input fields should be validate on 
ppr-parts.

Let me try to explain what I mean:
You have two selectOneSelectBoexes. The second is a 'subbox' of the first. If 
the user change the first on, the second should be rerendered with new entries.
Both are required like some other input fields on the page. If any of the 
required fields is empty the validation will fail. But for the rerendering of 
the second selectbox this validation isn't necessary.

I hope it is clear, what I mean.

Best regards
Björn


 -Ursprüngliche Nachricht-
 Von: Ernst Fastl [mailto:[EMAIL PROTECTED]
 Gesendet: Mittwoch, 27. September 2006 22:36
 An: MyFaces Development
 Betreff: Re: Enhancing Partial Page Rendering

 A automatic refresh after a given timeout is another good idea. I think
 this would be great for status-boards. lets add this to the list :-)

 What I meant with point number 2 is intended, that you just sourround
 a group of components with a pprPanelGroup and no matter which
 of theese components is clicked, the pprPanalGroup updates itself
 via AJAX without needing to specify triggers or a regex for the contained
 component.

 The Idea behind this is to make it really easy to ajaxize existing
 applications
 by for instance sourrounding a datatable with its scoller just with a
 pprPanelGroup
 - set triggerOnContainedComponents ( or whatever we will call this) to
 true -
 and the area is ajaxed

 regards

 Ernst

 On 9/27/06, Gerald Müllan [EMAIL PROTECTED] wrote:
  Ernst,
 
  many thanks for your recent patches and the comments on it.
 
  I will test the changes today and commit the stuff afterwards.
 
  BTW, the second one of your future plans; is it like an automatically
  refresh after a given timeout? Seems very practicable to me.
 
  cheers,
 
  Gerald
 
  On 9/27/06, Ernst Fastl [EMAIL PROTECTED] wrote:
   Hello everyone!
  
   In the recent tomahawk issues related to the pprPanelGroup partial
 Page
   Rendering has been improved in the following points:
  
   -partialTriggers also work for commandLinks, selectOneMenu and
   selectBooleanCheckBox (the last two still need onchange-Handlers)
  
   -partialTriggers are also working between different forms now
  
   -the partialTriggerPattern Attribute has been introduced: a regular
 expression
   - all matching ClientIds act as triggering Components
  
   -the inlineLoadingMessage Attribute has been introduced- to display
   a loading message replacing the pprPanelGroup - content immediatly
   while waiting for the servers response
  
   since the patches are not yet commited these features are not yet in
   but they seem to work quite fine on my machine
  
   next steps  I have in mind include:
  
   -support nesting of pprPanelgroups which are not rendered in the first
 place
   (some javascript transportation over xml and eval() on the client side
   or similar ...
  
   -support of an attribute to automatically trigger on all components
 inside
   the pprPanelGroup
  
   -support an attribute to refresh a pprPanelGroup always if any
   partialTrigger triggers
   a partial reload
  
   -suport a general loading message right top of the screen
  
   suggestions are always welcom :-)
  
   I still have a problem with the component tree and server side state-
 saving
   since I don't forward to the JSP-engine. If I understood the outcome
 of
   the thread Problems with Partial Page Rendering correctly it will
   be possible to create the component tree and invoke state-saving
   without actually rendering. I'd appreciate that very much because
   at the moment this is still missing in PPR and I don't know how to
   do that.
  
   thanks for all the interesing information in the PPR related threads
  
   Ernst
  
 
 
  --
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 

Enhancing Partial Page Rendering

[Ernst Fastl]

Hello everyone!

In the recent tomahawk issues related to the pprPanelGroup partial Page
Rendering has been improved in the following points:

-partialTriggers also work for commandLinks, selectOneMenu and
selectBooleanCheckBox (the last two still need onchange-Handlers)

-partialTriggers are also working between different forms now

-the partialTriggerPattern Attribute has been introduced: a regular expression
- all matching ClientIds act as triggering Components

-the inlineLoadingMessage Attribute has been introduced- to display
a loading message replacing the pprPanelGroup - content immediatly
while waiting for the servers response

since the patches are not yet commited these features are not yet in
but they seem to work quite fine on my machine

next steps  I have in mind include:

-support nesting of pprPanelgroups which are not rendered in the first place
(some javascript transportation over xml and eval() on the client side
or similar ...

-support of an attribute to automatically trigger on all components inside
the pprPanelGroup

-support an attribute to refresh a pprPanelGroup always if any
partialTrigger triggers
a partial reload

-suport a general loading message right top of the screen

suggestions are always welcom :-)

I still have a problem with the component tree and server side state-saving
since I don't forward to the JSP-engine. If I understood the outcome of
the thread Problems with Partial Page Rendering correctly it will
be possible to create the component tree and invoke state-saving
without actually rendering. I'd appreciate that very much because
at the moment this is still missing in PPR and I don't know how to
do that.

thanks for all the interesing information in the PPR related threads

Ernst

Re: Enhancing Partial Page Rendering

[Ernst Fastl]

A automatic refresh after a given timeout is another good idea. I think
this would be great for status-boards. lets add this to the list :-)

What I meant with point number 2 is intended, that you just sourround
a group of components with a pprPanelGroup and no matter which
of theese components is clicked, the pprPanalGroup updates itself
via AJAX without needing to specify triggers or a regex for the contained
component.

The Idea behind this is to make it really easy to ajaxize existing applications
by for instance sourrounding a datatable with its scoller just with a
pprPanelGroup
- set triggerOnContainedComponents ( or whatever we will call this) to true -
and the area is ajaxed

regards

Ernst

On 9/27/06, Gerald Müllan [EMAIL PROTECTED] wrote:

Ernst,

many thanks for your recent patches and the comments on it.

I will test the changes today and commit the stuff afterwards.

BTW, the second one of your future plans; is it like an automatically
refresh after a given timeout? Seems very practicable to me.

cheers,

Gerald

On 9/27/06, Ernst Fastl [EMAIL PROTECTED] wrote:
 Hello everyone!

 In the recent tomahawk issues related to the pprPanelGroup partial Page
 Rendering has been improved in the following points:

 -partialTriggers also work for commandLinks, selectOneMenu and
 selectBooleanCheckBox (the last two still need onchange-Handlers)

 -partialTriggers are also working between different forms now

 -the partialTriggerPattern Attribute has been introduced: a regular expression
 - all matching ClientIds act as triggering Components

 -the inlineLoadingMessage Attribute has been introduced- to display
 a loading message replacing the pprPanelGroup - content immediatly
 while waiting for the servers response

 since the patches are not yet commited these features are not yet in
 but they seem to work quite fine on my machine

 next steps  I have in mind include:

 -support nesting of pprPanelgroups which are not rendered in the first place
 (some javascript transportation over xml and eval() on the client side
 or similar ...

 -support of an attribute to automatically trigger on all components inside
 the pprPanelGroup

 -support an attribute to refresh a pprPanelGroup always if any
 partialTrigger triggers
 a partial reload

 -suport a general loading message right top of the screen

 suggestions are always welcom :-)

 I still have a problem with the component tree and server side state-saving
 since I don't forward to the JSP-engine. If I understood the outcome of
 the thread Problems with Partial Page Rendering correctly it will
 be possible to create the component tree and invoke state-saving
 without actually rendering. I'd appreciate that very much because
 at the moment this is still missing in PPR and I don't know how to
 do that.

 thanks for all the interesing information in the PPR related threads

 Ernst



--
http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Created: (TOMAHAWK-707) PPRPanelGroup partialTriggerPattern js-function produces JS-error when invoked with non-string object

[Ernst Fastl (JIRA)]

PPRPanelGroup partialTriggerPattern js-function produces JS-error when invoked 
with non-string object
-

 Key: TOMAHAWK-707
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-707
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


PPRPanelGroup partialTriggerPattern js-function produces JS-error when invoked 
with non-string object.
This JavaScript-Funciton needs additional type checking to work more reliable

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-708) PPRPanelGroup should support an inline Loading Message

[Ernst Fastl (JIRA)]

PPRPanelGroup should support an inline Loading Message
--

 Key: TOMAHAWK-708
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-708
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


PPRPanelGroup should support an inline Loading Message to avoid Users clicking 
on Elements
which are already rerequested from the server or just to give the application a 
more interactive feeling

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-708) PPRPanelGroup should support an inline Loading Message

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-708?page=all ]

Ernst Fastl updated TOMAHAWK-708:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup should support an inline Loading Message
 --

 Key: TOMAHAWK-708
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-708
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: tomahawk-708.patch


 PPRPanelGroup should support an inline Loading Message to avoid Users 
 clicking on Elements
 which are already rerequested from the server or just to give the application 
 a more interactive feeling

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-707) PPRPanelGroup partialTriggerPattern js-function produces JS-error when invoked with non-string object

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-707?page=all ]

Ernst Fastl updated TOMAHAWK-707:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup partialTriggerPattern js-function produces JS-error when 
 invoked with non-string object
 -

 Key: TOMAHAWK-707
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-707
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


 PPRPanelGroup partialTriggerPattern js-function produces JS-error when 
 invoked with non-string object.
 This JavaScript-Funciton needs additional type checking to work more reliable

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-695) PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and selectBooleanCheckBox

[Ernst Fastl (JIRA)]

PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and 
selectBooleanCheckBox
-

 Key: TOMAHAWK-695
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-695
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


If the ids of commandLinks, selectOneMenus or Checkboxes are used in the 
partialTriggers Attribute of 
a PPRPanelGroup the form is still submitted normaly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-695) PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and selectBooleanCheckBox

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-695?page=all ]

Ernst Fastl updated TOMAHAWK-695:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and 
 selectBooleanCheckBox
 -

 Key: TOMAHAWK-695
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-695
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


 If the ids of commandLinks, selectOneMenus or Checkboxes are used in the 
 partialTriggers Attribute of 
 a PPRPanelGroup the form is still submitted normaly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-696) PPRPanelGroup partialTriggers don't support ValueBindings

[Ernst Fastl (JIRA)]

PPRPanelGroup partialTriggers don't support ValueBindings
-

 Key: TOMAHAWK-696
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-696
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


valueBindings can't be used for the partialTriggers Attribute

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-696) PPRPanelGroup partialTriggers don't support ValueBindings

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-696?page=all ]

Ernst Fastl updated TOMAHAWK-696:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup partialTriggers don't support ValueBindings
 -

 Key: TOMAHAWK-696
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-696
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: tomahawk-696.patch


 valueBindings can't be used for the partialTriggers Attribute

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-697) PPRPanelGroup panelGroup insert renderd spans into each other when repeatetly refreshing

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-697?page=all ]

Ernst Fastl updated TOMAHAWK-697:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup panelGroup insert renderd spans into each other when repeatetly 
 refreshing
 

 Key: TOMAHAWK-697
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-697
 Project: MyFaces Tomahawk
  Issue Type: Bug
Reporter: Ernst Fastl
Priority: Minor

 If  a page is refreshed partially more often the rendered span always inserts 
 itself into itself over and over again

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-697) PPRPanelGroup panelGroup insert renderd spans into each other when repeatetly refreshing

[Ernst Fastl (JIRA)]

PPRPanelGroup panelGroup insert renderd spans into each other when repeatetly 
refreshing


 Key: TOMAHAWK-697
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-697
 Project: MyFaces Tomahawk
  Issue Type: Bug
Reporter: Ernst Fastl
Priority: Minor


If  a page is refreshed partially more often the rendered span always inserts 
itself into itself over and over again

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-698) PPRPanelGroup Post-Information is submitted twice when using PPR

[Ernst Fastl (JIRA)]

PPRPanelGroup Post-Information is submitted twice when using PPR


 Key: TOMAHAWK-698
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-698
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


This happens when the original Button onclick-Handler is called and the submit 
function afterwards

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-695) PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and selectBooleanCheckBox

[Ernst Fastl (JIRA)]

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-695?page=comments#action_12437506 
] 

Ernst Fastl commented on TOMAHAWK-695:
--

the selectOneMenu-components and selectBooleanCheckBox need to call the 
oamSubmitForm - funciton in the onChange-handler
to enable them as partialTriggers as shown in the example

 PPRPanelGroup partialTriggers don't work for commandLink, selectOneMenu and 
 selectBooleanCheckBox
 -

 Key: TOMAHAWK-695
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-695
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
 Assigned To: Gerald Müllan
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: tomahawk-695.patch


 If the ids of commandLinks, selectOneMenus or Checkboxes are used in the 
 partialTriggers Attribute of 
 a PPRPanelGroup the form is still submitted normaly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-700) enable shareing partialTriggers between Forms

[Ernst Fastl (JIRA)]

enable shareing partialTriggers between Forms
-

 Key: TOMAHAWK-700
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-700
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Reporter: Ernst Fastl
Priority: Minor


partialTriggers currently only work within the form the PPRPanelGroup is 
defined. 
this should be enhanced by defining them on a per window basis to enable 
updates from multiple forms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-700) enable shareing partialTriggers between Forms

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-700?page=all ]

Ernst Fastl updated TOMAHAWK-700:
-

Status: Patch Available  (was: Open)

 enable shareing partialTriggers between Forms
 -

 Key: TOMAHAWK-700
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-700
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: PPRPanelGroup
Reporter: Ernst Fastl
Priority: Minor

 partialTriggers currently only work within the form the PPRPanelGroup is 
 defined. 
 this should be enhanced by defining them on a per window basis to enable 
 updates from multiple forms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-702) PPRPanelGroup support a regular Expression as partialTrigger attribute

[Ernst Fastl (JIRA)]

PPRPanelGroup support a regular Expression as partialTrigger attribute
--

 Key: TOMAHAWK-702
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-702
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


Support a new Attribute which takes a regular Expression. if the Client-ID of a 
submitting component matches
this expression, a partial Update of the corresponding Group is performed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-702) PPRPanelGroup support a regular Expression as partialTrigger attribute

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-702?page=all ]

Ernst Fastl updated TOMAHAWK-702:
-

Status: Patch Available  (was: Open)

 PPRPanelGroup support a regular Expression as partialTrigger attribute
 --

 Key: TOMAHAWK-702
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-702
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: PPRPanelGroup
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Ernst Fastl
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: tomahawk-702.patch


 Support a new Attribute which takes a regular Expression. if the Client-ID of 
 a submitting component matches
 this expression, a partial Update of the corresponding Group is performed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-640) Javascript-Code broken when using 2 or more PPRPanelGroups

[Ernst Fastl (JIRA)]

Javascript-Code broken when using 2 or more PPRPanelGroups
--

 Key: TOMAHAWK-640
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-640
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: New Component
Reporter: Ernst Fastl


Recent changes lead to an infinite recursion in the Button-onclick-handler 
replacement functions if 2 or
more PanelGroups are used on the page.

To provide the intended functionality of the previous change the PPRCtrl 
Objects should be attached to the form
which they are responsible for and the PPRPanelGroupRenderer should remember by 
setting Parameters
in the RequestParameterMap for which forms PPRCtrl has already been initialized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-640) Javascript-Code broken when using 2 or more PPRPanelGroups

[Ernst Fastl (JIRA)]

 [ http://issues.apache.org/jira/browse/TOMAHAWK-640?page=all ]

Ernst Fastl updated TOMAHAWK-640:
-

Status: Patch Available  (was: Open)

 Javascript-Code broken when using 2 or more PPRPanelGroups
 --

 Key: TOMAHAWK-640
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-640
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: New Component
Reporter: Ernst Fastl

 Recent changes lead to an infinite recursion in the Button-onclick-handler 
 replacement functions if 2 or
 more PanelGroups are used on the page.
 To provide the intended functionality of the previous change the PPRCtrl 
 Objects should be attached to the form
 which they are responsible for and the PPRPanelGroupRenderer should remember 
 by setting Parameters
 in the RequestParameterMap for which forms PPRCtrl has already been 
 initialized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Suggestions for PPRPanelGroup Improvements

[Ernst Fastl]

Hi again,

after updating and looking through the code again, I found out that
Mario already fixed the most important issues. Thanks for that.
Still open are:

1. Update the JSF sequence when doing partial updates

2. Support Client-Side State-Saving

3. Don't render the JS-Code for registering the partial Triggers in
AJAX-Response (already started on Server side, js-code still
needs to be changed)

4. Support partially adding components which include js-files with the
AddResource

5. Support the Browser Back-Button by fetching the page with the
corresponding JSF-Sequence

6. Support a Attribute to trigger partial updates by all contained elements
(updateByInnerComponents=true ? suggestions for a good name? )

Please correct me if I am wrong with any of those.

Also still open the question of how to create the PPRPanelGroup
as a new component in JIRA :-).

regards

Ernst


On 8/26/06, Ernst Fastl [EMAIL PROTECTED] wrote:

Hi,

If I understood the recent discussions correctly we should
create JIRA Issues seperately for every change we want to make
rather than Issues like Enhancing component x. Following
List are suggestions for improvements to the PPRPanelGroup.


1. Update the JSF sequence when doing partial updates

2. Support Client-Side State-Saving

3. Don't render the JS-Code for registering the partial Triggers in
AJAX-Response

4. Support partially adding components which include js-files with the
AddResource

5. avoid Log Message: DefaultAddResource - Response has no head or
body tag: for XML-Response

6. Support the Browser Back-Button by fetching the page with the
corresponding JSF-Sequence

7. Support a Attribute to trigger partial updates by all contained elements
(updateByInnerComponents=true ? suggestions for a good name? )


Other suggestions are welcome. If nobody has any objections
I would create JIRA Issues for every one of them.

Should I add them to MyFaces Tomahawk - New Component or is
it possible to create the PPRPanelGroup as a component in JIRA ?

Since this are a lot of changes I will probably not be
able to fix all of them before the next release. Is creating
the JIRA issues now  in conflict with the release policy
if they are not fixed befor the next release?


regards

Ernst

Re: Suggestions for PPRPanelGroup Improvements

[Ernst Fastl]

Thanks for the Information!

I also like the Idea of having a single Enhancing PPRPanelGroup issue.
But I'll put not all of the suggestions in there to
be sure I'll be able to finish them within reasonable time ( weeks ).
And also because, there are some points for which I don't have any Ideas
how to implement them yet. Also some of them will probably need to
be discussed like for instance the Client-Side State saving.

however, thanks for the support

kind regards

Ernst


On 8/28/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

On 8/26/06, Ernst Fastl [EMAIL PROTECTED] wrote:
 If I understood the recent discussions correctly we should
 create JIRA Issues seperately for every change we want to make
 rather than Issues like Enhancing component x.

No, that's not really what's being said.
Every change should be associated with a Jira issue, but a jira issue
can be associated with many changes, as long as it's reasonable :-)

I'd say that Enhancing component x is fine as a single jira issue
provided that all of these changes are going to be made within the
same period of time.

What we don't want to do is have code changes without jira issues
(that's the biggest problem), nor do we want to have never-ending jira
issues that can't be closed because they cover too many tasks.


 Should I add them to MyFaces Tomahawk - New Component or is
 it possible to create the PPRPanelGroup as a component in JIRA ?

I'll create PPRPanelGroup for you.   Until someone creates a new
component entry, I think using new component makes the most sense.

 Since this are a lot of changes I will probably not be
 able to fix all of them before the next release. Is creating
 the JIRA issues now  in conflict with the release policy
 if they are not fixed befor the next release?

For improvements, I'd say as long as you're planning to work on them,
go ahead and create the issues.   Just set the fix version to be the
newest snapshot.

Considering the next release is probably months away, it's unlikely to
be problem in any case.