[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
