[Decapod] Capture demo, JIRA gardening, next steps

Boyan Sheytanov boyan.sheytanov at asteasolutions.com
Mon Jan 11 16:48:13 UTC 2010

Hi there!

I took a look at the issues Michelle wrote about and resolved some of them
(not commited yet). See my comments inline and replies to Jonathan and Colin

2010/1/8 Michelle D'Souza <michelle.dsouza at utoronto.ca>

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

OK, I will file JIRAs for these two issues.

> 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 tomorrow.
> line 89
> 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.

I see your point - I should probably change that (I tried it today and it
lead to some strange behaviour, will look at it again soon).

> line 171
> Putting the markup for the delete button in the javascript file 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.

Already did this, a much better solution.

> line 243
> The URL on this line should be parameterized so that it's easy to
> configure.

It's not the only place we have an URL or path to a file. I'm considering
extracting these to a JSON config file but haven't worked on its structure
yet. We might want to store project settings there as well (book title,
stage of processing, model, etc...) but I need some time to think about it.
We might also discuss it at some of our next meetings.

> line 308
> 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.

Well, these are actually wrongly named capture selectors. I renamed them.

> I hope this is helpful and I'd like to hear your thoughts.
> Michelle
Jon, the answer to your question is that the instance running on my machine
is a live build - any changes I make to the code while developing (including
some that break it) are instantly reflected. Also, some downtime might be
expected. Thanks for the JIRA gardening, it's easier to stay on track when
things are not bogged with old issues.

Colin, here's a list of Python packages I needed to install on my Debian
machine before I could run the server: cherrypy3, numpy, matplotlib. I'm
running python 2.5.2. You need to start the server in the directory where
the dserver.py file is (paths are configured relative to that folder). When
you deploy the application, you might want to set the serverOn option to
true. Can't think of anything else that is needed.

Greetings, Boyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100111/bbd09ce9/attachment.html>

More information about the fluid-work mailing list