You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Markus Joschko (JIRA)" <ta...@jakarta.apache.org> on 2005/08/11 13:58:54 UTC

[jira] Created: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Hook into the rendering process for AJAX improvement
----------------------------------------------------

         Key: TAPESTRY-545
         URL: http://issues.apache.org/jira/browse/TAPESTRY-545
     Project: Tapestry
        Type: Improvement
  Components: Framework  
    Versions: 4.0    
    Reporter: Markus Joschko
    Priority: Minor


I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 

The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".

For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734

At the end I can only see one possibility (or maybe two, but the second one is dirty):

-add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.

the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.

-the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.

As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?


-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


[jira] Closed: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
     [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=all ]
     
Jesse Kuhnert closed TAPESTRY-545:
----------------------------------

    Fix Version: unspecified
     Resolution: Invalid
      Assign To: Jesse Kuhnert

This is already handleable via the EnhancementWorker chain logic in hivemind. A better solution should hopefully come out in the 4.1 release. 

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement
>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Assignee: Jesse Kuhnert
>     Priority: Minor
>      Fix For: unspecified

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


[jira] Updated: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Brian K. Wallace (JIRA)" <ta...@jakarta.apache.org>.
     [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=all ]

Brian K. Wallace updated TAPESTRY-545:
--------------------------------------

    Fix Version: 4.1
                     (was: unspecified)

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement

>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Assignee: Jesse Kuhnert
>     Priority: Minor
>      Fix For: 4.1

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


[jira] Commented: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
    [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=comments#action_12318898 ] 

Jesse Kuhnert commented on TAPESTRY-545:
----------------------------------------

This is being worked on in a related project, tacos.sourceforge.net. Reference implementation will be available soon. 

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement
>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Priority: Minor

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


[jira] Commented: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
    [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=comments#action_12318947 ] 

Jesse Kuhnert commented on TAPESTRY-545:
----------------------------------------

Not wanting to butt in or anything....but this would seem to only get us halfway there. The ability to call renderComponent on a specific component I think is already there, though you do have to write some sort of engine service to control how to pass in the writer. 

I think the ideal scnerio would be :

-) A way to add behaviour to the render cycle which allows a contributed service to determine which IMarkupWriter any given component in the system is passed. This would mean some sort of interface that would pass in the IComponent instance itself to the check?

OR

The IPage suggestion you had would work, only if there were a corresponding engine service that could dole out renders to a list of components, as it may be desirable to have more than one component rendered in a particular request. ....

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement
>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Priority: Minor

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


[jira] Commented: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
    [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=comments#action_12318949 ] 

Jesse Kuhnert commented on TAPESTRY-545:
----------------------------------------

Not that this is the right way at all, but for a clearer picture of what sort of problems are being placed, take a look at http://cvs.sourceforge.net/viewcvs.py/tacos/tacos4/src/net/sf/tacos/partial/?only_with_tag=prototype-ajax

Anything starting with the word Ajax in that particular directory are some of the things being dealt with...

It would be nice to eliminate the need for a new EngineService as well, but then how do you pass in the "id"s of the components that you need refreshed "globally"? Can IRequestCycle steal a particular set of parameters and kind of do it automatically? 

The implementation listed above is using jwcid Component id's when they are provided, and if not, it tries to use the html id="" attribute specified on the component. 

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement
>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Priority: Minor

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


[jira] Commented: (TAPESTRY-545) Hook into the rendering process for AJAX improvement

Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
    [ http://issues.apache.org/jira/browse/TAPESTRY-545?page=comments#action_12318944 ] 

Howard M. Lewis Ship commented on TAPESTRY-545:
-----------------------------------------------

Seems like what you may want is the ability to start the rendering process inside a page, at an arbitrary component, rather than at the page itself.

Perhaps an additional method on IPage to say "render this component" rather than the default "render yourself".

> Hook into the rendering process for AJAX improvement
> ----------------------------------------------------
>
>          Key: TAPESTRY-545
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-545
>      Project: Tapestry
>         Type: Improvement
>   Components: Framework
>     Versions: 4.0
>     Reporter: Markus Joschko
>     Priority: Minor

>
> I added this feature request in the hope, that we might find a solution on how to simplify the AJAX support in tapestry.
> It currently requires a special "Part" component which exchanges its markupwriter during rendering. As all components not contained in such a "Part" use a Nullwriter, this approach allows to only render specified components. 
> The disadvantage with this is, that the part component is absolutely required. It would be much nicer if all components could be marked as "to be rendered".
> For a discussion which approaches are possible see http://thread.gmane.org/gmane.comp.jakarta.tapestry.devel/6734
> At the end I can only see one possibility (or maybe two, but the second one is dirty):
> -add a wrapMethodImplementation(Class,MethodSignature,String,String) method to the EnhancementOperation interface which allows to do kind of AOP magic to the renderComponent method of each component. This would allow to switch the markupwriter in all renderComponent methods of all components.
> the disadvantage: the enhancementworker who does this must come very late in the chain. Otherwise other enhancementworkers could add code before or after the wrapped code.
> -the dirty one: using a little enhancement for the prepareforRender method in combination with threadlocals, the partialservice and a special markupwriter  could achieve the same. But this would require to make the markupwriter more clever than it should be. not nice.
> As already mentioned in the e-mail discussion: I can't see any other possibilities. But maybe someone else?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org