[uportal-dev] Questions regarding uPortal portlet moveability and precedence
Eric Dalquist
eric.dalquist at doit.wisc.edu
Tue Nov 6 17:21:33 UTC 2007
Anastasia Cheetham wrote:
>
> Eric, thanks for your answers to our questions. This really helps us
> to understand how the valid and invalid drop targets in the example
> were determined.
>
>> 2. Precedence is only useful when deciding if a movable portlet can
>> be moved above an immovable portlet. If both portlets are marked
>> movable precedence doesn't matter.
>
> Ok. So then in the example on the wiki
> (http://wiki.fluidproject.org/x/FAka), p3 can't be moved above p1 only
> because of the presence of p2, which is immovable and of higher
> precendence - is that right? If the immovable portlet wasn't there,
> then p3 could be moved above p1?
Correct.
>
>> And the grand summary of all of this is the reorderer shouldn't care
>> about any of it. The goal with the JSON objects is to hide 100% of
>> this logic and just describe the general structure of the objects the
>> reorderer will be working with and where each object can be moved to.
>
> Yes, we do understand that. But having an understanding of how things
> work will help us to develop appropriate test cases and generate the
> associated test data, among other things. Having an understanding of
> how portlets are allowed (and not allowed) to move around helps us to
> define intelligent default movement behaviour.
>
> And I just like to understand how things work :-)
Very understandable as I'm sure we all do :) I just wanted to make sure
you weren't going to be coding that logic into the reorderer.
>
>
> Again, thanks for your clarifications.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3336 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071106/cea445e0/attachment.bin>
More information about the fluid-work
mailing list