[Plone-UI] Review on content finder widget

Dylan Jay djay at pretaweb.com
Mon Jan 21 11:05:00 UTC 2013


On 21/01/2013, at 7:35 PM, Roché Compaan <roche at upfrontsystems.co.za> wrote:

> On Mon, Jan 21, 2013 at 10:01 AM, Dylan Jay <djay at pretaweb.com> wrote:
>> 
>> On 21/01/2013, at 6:34 PM, Roché Compaan <roche at upfrontsystems.co.za> wrote:
>> 
>>> Stabilising it inside p.a.widgets could take a long time and it
>>> doesn't really give anybody using a different platform the opportunity
>> 
>> I tend to think it will work quicker the other way around. Realistically have you have to get it to a level where it is stable before others will want to us it and improve it. At least thats my experience with releasing opensource software.
> 
> IMO It's stable enough for somebody to pick up and do something useful
> with it. If there was a widget like this in existence when we looked
> for one at the Plone conf, I'm sure we would have seriously considered
> using it.
> 
> The only major feature that is outstanding is searching which is very
> similar to browsing implementation wise. I was planning to implement
> this as part of the cleanup of the JS and CSS. Once this is done I
> expect us making small bug fixes to the js code and spending most of
> our time doing Plone integration in p.a.widgets.
> 
>> We need a referencebrowser in order to complete the p.a.toolbar so there is high motivation to get it to at least work for that usecase.
>> 
>> 
>>> to help stabilise it. Inside p.a.widgets it will stay hidden and there
>>> is always the risk of introducing Plone specific changes because it
>>> lives inside p.a.widgets.
>> 
>> There is high motivation to ensure that this doesn't happen. It's much more useful to Plone to have a widget built on well supported js code and the more its used outside of Plone the more support there is available.
>> The suggestion is just to move it into p.a.widgets for a period of a few weeks till it's get stable enough to be released to the public as a jquery widget. At that time it would need it's own repo. Alternatively if someone can think of a way we can use a js github package with mr.developer and pypi?
> 
> I don't see why we can't do this right from the beginning, there's
> very little overhead in doing so and whatever overhead there is I'm
> willing to handle.  If Plone developers want to make bugfixes to the
> js code in p.a.widgets, that's fine too - I'll keep the js only repo
> in sync.
> 
>>> I'll rather make a repo under my own account and copy the js across to
>>> p.a.widgets, we don't have to let repo discussions delay the process.
>> 
>> Then we are stuck waiting for you and can't help.
> 
> Giving somebody access to a repo, or accepting pull requests doesn't
> really leave you stuck. As long as there is the opportunity for other
> developers outside Plone to fork it and makes changes, we're in a
> better position than hiding it in p.a.widgets.
> 
>> This seems a worse solution than a dependent collective repo.
> 
> Yes collective repo is certainly better, I only suggested my own
> account since there seems be resistance against a separate repo all
> together.

There's no resistance against a separate repo, just suggesting the quickest ways to evolve it in conjunction with p.a.widgets.

What if it's in it's own repository which also includes setup.py, zcml etc so it can be directly imported as a resource into Plone? These would be ignored by anyone else using it outside Plone. They could be deleted later. 

> 
> --
> Roché Compaan
> Upfront Systems                   http://www.upfrontsystems.co.za



More information about the UI mailing list