[Decapod] Capture demo, JIRA gardening, next steps
michelle.dsouza at utoronto.ca
Fri Jan 8 19:38:07 UTC 2010
Thanks for putting this together Boyan. To answer your questions -
yes, JIRAs need to be filed for the move from scratchpad to incubator
as well as for the build server work.
Here are a few things to think about that came out of the code tour
you gave yesterday - nothing major. I'll likely send some more along
Using 'find' to get the delete button out of the DOM implies an API
restriction on the selector a user gives for 'deleteButton'. The
selector will need to work relative to the containing item. If this is
something that we really want to do, then we should document the API
clearly however, we should consider whether we want to put this
constraint on users of the component. One example of how someone may
change their use of the component where this implementation would not
work is if they moved the delete link out of the item and instead had
a single delete button. If this were a core Infusion component then I
would say we must change it, however, with decapod components we have
a little more space to limit flexibility in the use of the components.
constrains users to this particular markup. It also negates the
configurability of the selector for the delete button since it is in
essence hard coded in this markup snippet. An alternative is to
include the markup for the delete button hidden in the template and
use show and hide as required. This will also get rid of the need to
recreate the delete button every time an item gets focus.
The URL on this line should be parameterized so that it's easy to
I'm curious about the 'flc-imageReorderer' selectors inside capture.
It feels to me that these are part of the capture component not the
image reorderer. The image reorderer should define its own selectors
in its component code. Perhaps I'm misunderstanding this.
I hope this is helpful and I'd like to hear your thoughts.
More information about the fluid-work