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