You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org> on 2005/08/20 19:23:54 UTC
[jira] Created: (TAPESTRY-575) Provide component clipping bounds
Provide component clipping bounds
---------------------------------
Key: TAPESTRY-575
URL: http://issues.apache.org/jira/browse/TAPESTRY-575
Project: Tapestry
Type: Improvement
Components: Framework
Versions: 4.0
Environment: conditional rendering/ aka ajax
Reporter: Jesse Kuhnert
Priority: Minor
The current framework is already so close to looking like a client side GUI rendering engine, it would seem logical to provide the next level of support for this sort of rendering model, which is basically what ajax is. The model has changed from needing to re-render the entire page back to the client, to being able to intelligently request that only certain "areas" be rendered...Much like apple's innovation with introducing the concept of "clipping bounds", I think tapestry could do exactly the same thing. As an example, a gui render request might do something sort of like this:
public void paintComponent(Graphics g)
{
super.paintComponent(g);
try {
boolean rePaint = false;
Graphics2D g2 = (Graphics2D)g;
Rectangle dim = getBounds();
Rectangle bounds = g.getClipBounds();
Rectangle2D.Double cBounds = null;
if (bounds == null)
cBounds = new Rectangle2D.Double(getBounds().x, getBounds().y, getBounds().width, getBounds().height);
else
cBounds = new Rectangle2D.Double(bounds.x, bounds.y, bounds.width, bounds.height);
} .....
}...
I have already done the hard part, which is setting up the request and environment so that knowledge of the clipping bounds is easily attained. Injecting an AjaxWebResponse is now possible for any component/service/etc...If we could just carry this over to tapestry full render efficiency happiness would be complete:
protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle)
{
Iterator dataSource = getSourceData();
// The dataSource was either not convertable, or was empty.
if (dataSource == null)
return;
IAjaxRequestCycle ajaxCycle = (IAjaxRequestCycle)cycle; //I'm just teasing here, but something.....
if (!ajaxCycle.isRequestedRender(this))
return;
boolean indexBound = isParameterBound("index");
boolean valueBound = isParameterBound("value");
String element = getElement();
....
...
}....
The only non-standard part of this is that I've had to check both the components normal getId() as well as the informal parameter (where allowed) attribute of "id" to be able to easily let users specify which parts of their page they want refreshed. ..If we added something in here, then it would just be a matter of when component devs/contributors had time to go in and make their component more efficient....
I'm able to do direct component updates already, but have had to actually iterate through the components of a page to determine if they are contained by things like Foreach.
Of course this is just one step. It would seem with all of the changeObserver and parameter binding logic that you already have in place, the next logical step for the framework would be to dynamically determine which components needed to be refreshed (clipping bounds) and which did not without users having to specify it at all...Such as the case where a user selects an item in a list, or updates the local parameter of a page and only causes renders of component areas that use that parameter to render something else...You know what I mean..
I can't help but think that some of the source of inspiration for your request cycle had to come from gui development experience, where things like this make the difference between a clean, responsive gui, and that of a slow and "ghosted paint" gui where the screen can't re-paint the different areas fast enough for the user to notice black holes..
my 2 cents.
--
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-575) Provide component clipping bounds
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-575?page=all ]
Jesse Kuhnert closed TAPESTRY-575:
----------------------------------
Resolution: Won't Fix
Not a valid enhancement. Be more specific ;)
> Provide component clipping bounds
> ---------------------------------
>
> Key: TAPESTRY-575
> URL: http://issues.apache.org/jira/browse/TAPESTRY-575
> Project: Tapestry
> Type: Improvement
> Components: Framework
> Versions: 4.0
> Environment: conditional rendering/ aka ajax
> Reporter: Jesse Kuhnert
> Priority: Minor
>
> The current framework is already so close to looking like a client side GUI rendering engine, it would seem logical to provide the next level of support for this sort of rendering model, which is basically what ajax is. The model has changed from needing to re-render the entire page back to the client, to being able to intelligently request that only certain "areas" be rendered...Much like apple's innovation with introducing the concept of "clipping bounds", I think tapestry could do exactly the same thing. As an example, a gui render request might do something sort of like this:
> public void paintComponent(Graphics g)
> {
> super.paintComponent(g);
> try {
>
> boolean rePaint = false;
> Graphics2D g2 = (Graphics2D)g;
>
> Rectangle dim = getBounds();
> Rectangle bounds = g.getClipBounds();
> Rectangle2D.Double cBounds = null;
> if (bounds == null)
> cBounds = new Rectangle2D.Double(getBounds().x, getBounds().y, getBounds().width, getBounds().height);
> else
> cBounds = new Rectangle2D.Double(bounds.x, bounds.y, bounds.width, bounds.height);
> } .....
> }...
> I have already done the hard part, which is setting up the request and environment so that knowledge of the clipping bounds is easily attained. Injecting an AjaxWebResponse is now possible for any component/service/etc...If we could just carry this over to tapestry full render efficiency happiness would be complete:
> protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle)
> {
> Iterator dataSource = getSourceData();
> // The dataSource was either not convertable, or was empty.
> if (dataSource == null)
> return;
> IAjaxRequestCycle ajaxCycle = (IAjaxRequestCycle)cycle; //I'm just teasing here, but something.....
> if (!ajaxCycle.isRequestedRender(this))
> return;
> boolean indexBound = isParameterBound("index");
> boolean valueBound = isParameterBound("value");
> String element = getElement();
> ....
> ...
> }....
> The only non-standard part of this is that I've had to check both the components normal getId() as well as the informal parameter (where allowed) attribute of "id" to be able to easily let users specify which parts of their page they want refreshed. ..If we added something in here, then it would just be a matter of when component devs/contributors had time to go in and make their component more efficient....
> I'm able to do direct component updates already, but have had to actually iterate through the components of a page to determine if they are contained by things like Foreach.
> Of course this is just one step. It would seem with all of the changeObserver and parameter binding logic that you already have in place, the next logical step for the framework would be to dynamically determine which components needed to be refreshed (clipping bounds) and which did not without users having to specify it at all...Such as the case where a user selects an item in a list, or updates the local parameter of a page and only causes renders of component areas that use that parameter to render something else...You know what I mean..
> I can't help but think that some of the source of inspiration for your request cycle had to come from gui development experience, where things like this make the difference between a clean, responsive gui, and that of a slow and "ghosted paint" gui where the screen can't re-paint the different areas fast enough for the user to notice black holes..
> my 2 cents.
--
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