i still think (we need that method anyway) thatparent.switchParent(IMoveable child) is better. (or what ever you wanna call it)It is compile save, instead of runtime and then it is just a marker and they don't have to implement moveTo()
(which is an internal thing in the end anyway)And people can
I get it now. By default such moving is not even supported - you can
create a new component for a parent or reattach older ones. However,
there are some case where you want to be able to move components to
new parents, e.g. gridview with item reuse == true. As the markup of a
component is relative
the attributes yes but also the markupid (when constructed by the completely hierarchy)johanOn 9/7/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:On 9/7/06, Igor Vaynberg <
[EMAIL PROTECTED]> wrote:> none of the code youve written so far counts unless are are writing an app> against 2.0 because the
we havent fully explored any of these usecases because the code that allows them is brand new <== what if you move this component somewhere where rowsperpage="20" - shouldnt that update?
now thats a simple example, and a pull model can helpwhat if now based on different attributes you create differ
On 9/7/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> none of the code youve written so far counts unless are are writing an app
> against 2.0 because the interfearing features here are only available in
> 2.0. and even then its a very young concept and code.
So which features are they then? Anyth
none of the code youve written so far counts unless are are writing an app against 2.0 because the interfearing features here are only available in 2.0. and even then its a very young concept and code.what we are talking about here is support moving by default - probably breaking things
or denying
I don't think it would be a problem to switch parents in most cases. I
can't even think of *one* in all the Wicket code I've written, and
I've used component switching a lot. What introducing this new
interface does - besides bloating the API further - is that it will
actually make it harder to wri
that would be bad. That will nobody implement. Nobody is going to think about that..Then just let it be moveable and be done with it and warn people about the possible dangerous things(like attributes and id/name changes becaues of the different hierarchy)
johanOn 9/7/06, Eelco Hillenius <[EMAIL PR
Well, if you really think we need such a thing and you want to go for
simplicity, I'd like to see a more optimistic approach: instead of an
interface that allows moving and denying by default, have an interface
that blocks moving by allow moving by default.
Eelco
On 9/7/06, Igor Vaynberg <[EMAIL
the first makes it a lot more work. if you design a component and dont think about it moving and another team member writes code that uses that component and moves it you can have some subtle bugs.(2) makes the moving part explicit - ie this component can be moved - that one cannot. so yeah its an
> 1) allow all components to be movable - that means the implementors of
> context sensitive components need to always implement the logic to allow
> their components to readjust when moved
>
> 2) only allow components that want to be moved to be movable - that means we
> dont provide a public api
what about the option:parent.addMovedChild(IMoveable)then it is always compile save and you only have to have moved() on the interface.johanOn 9/7/06,
Igor Vaynberg <[EMAIL PROTECTED]> wrote:
because components have access to a lot more information on creation it is not always safe to move them ar
because components have access to a lot more information on creation it is not always safe to move them around (switch parents) because the underlying markup changes, for exampleclass MyComponent extends Panel {
public MyComponent(...) { if (getAttributes().get("mode").equals("one")) { n
But what component will become the parent of the empty panel? :-)
Martijn
On 8/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> we could have something like
>
> component.moveToParent(parent) ( i don't like just component.setParent() )
>
> you do know that this could open up much more things.
we could have something likecomponent.moveToParent(parent) ( i don't like just component.setParent() )you do know that this could open up much more things.. You could make panels upfront by just giving them an empty panel parent (with the wizard or something)
and then move them to the right place
so whats the deal with this, i would like to upgrade the repeaters package. johan, you have the usecases in your app - how are they working now? do you have an idea of how the api would look?-Igor
On 8/8/06, Igor Vaynberg <[EMAIL PROTECTED]
> wrote:i just dont think its a very common usecase to do
i just dont think its a very common usecase to do that...thats all-IgorOn 8/8/06, Johan Compagner <
[EMAIL PROTECTED]> wrote:thats why i wanted at first that panels where roots (instead of only pages)
because with servoy we switch a lot of panels (to really different places in the markup of the pag
thats why i wanted at first that panels where roots (instead of only pages)because with servoy we switch a lot of panels (to really different places in the markup of the page) But a panel has its ownso the markup really never changes for the components .. The paths do.
The question is how many thin
i dont know. youd have to kinda switch the parent and the id together. set attributes i think we do need to keep, not sure. at least in this case the tag it is being reattached to is the same.i did say parent refactor is not without cons :)
-IgorOn 8/8/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
we could allow it somehow, but what to do with the attributes? Reload and throw the current once away? Keep what the developer did set?The markup should be relookuped (and the markup index reset)I dont know what problems could all arise when we do it.
But wouldnt repareting be a bit strange for the
On 8/8/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ive
actually been putting that off on purpose until we flush out more of
the 2.0. the problem here is that you need to be able to switch parents
of items which 2.0 doesnt allow right nowfor examplerow1: item1 item2 item3
row2: item4 item5now when
21 matches
Mail list logo
