You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/10/30 21:04:56 UTC

[jira] Resolved: (TAPESTRY-673) For bean no longer provides source iterator

     [ http://issues.apache.org/jira/browse/TAPESTRY-673?page=all ]
     
Howard M. Lewis Ship resolved TAPESTRY-673:
-------------------------------------------

    Resolution: Won't Fix
     Assign To: Howard M. Lewis Ship

The features you suggest will significantly undermine the stability of the For component; I would suggest you create your own component that operates the way you need it to.  I think you need a component that operates more like a Java while loop.

> For bean no longer provides source iterator
> -------------------------------------------
>
>          Key: TAPESTRY-673
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-673
>      Project: Tapestry
>         Type: Bug
>   Components: Framework
>     Versions: 4.0
>  Environment: Hivemind 1.1-RC-1, Geronimo 1.0-M4, Tapestry 4.0-beta-8
>     Reporter: Paul Russell
>     Assignee: Howard M. Lewis Ship

>
> The For component used to provide a sourceIterator property that allowed clients to get hold of the iterator being used by the component. In beta-8, this has been removed, presumably to prevent people from calling 'next' on the iterator and messing up the iteration.
> Unfortunately, this change has had two discrete impacts on the application I'm working on:
> 1) I can no longer use sourceIterator.hasNext() to determine if I'm on the last iteration. In my context, the For bean is being used to generate a breadcrumb trail, and the 'last' breadcrumb is rendered as simple text, rather than a link.
> 2) I can no longer use sourceIterator.remove() to remove a 'line item' from a form. While I can understand that for database driven applications, this isn't a desirable feature, for applications based on a services architecture, where forms constructed around JavaBeans of various types are the norm, this was a very useful feature indeed!
> Would it be possible to provide equivalent features to these in the next version? I'm more than happy to contribute a patch to expose appropriate methods, but wanted to check if there were any issues here that I wasn't aware of first!
> Let me know, meanwhile I'll have to roll back to beta-7 :( Have left priority at Major, since as far as I can see, there's no easy workaround to this, but can see that you might think that's over-selling the issue!
> Thanks,
> Paul

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