headers
whit | 3 Jan 2007 09:29
Picon

wicked update

I'm pretty close to being ready to "merge" though I think that the 
actual merge may only be some snippets of zcml(and a few interface 
applications).

made some good progress today and tied up a few existing loose ends. 
wicked can now be turned on and off via the persistent component 
registry.  I also implemented a media wiki style registration.

All that is really left is to make a control panel(panel could probably 
wait though?).

planning to get this wrapped up by this weekend if not sooner.

-w
Permalink | Reply | 2 comments |
headers
Martin Aspeli | 3 Jan 2007 09:54
Picon
Gravatar

Re: wicked update

whit wrote:
> I'm pretty close to being ready to "merge" though I think that the 
> actual merge may only be some snippets of zcml(and a few interface 
> applications).

The kind of merge we like :)

> made some good progress today and tied up a few existing loose ends. 
> wicked can now be turned on and off via the persistent component 
> registry.  I also implemented a media wiki style registration.

What is media wiki style registration?

> All that is really left is to make a control panel(panel could probably 
> wait though?).

Have you had a look at plone.app.controlpanel? Formlib galore :)

I'd say we can merge without a control panel but with sensible/safe 
defaults. Having the control panel would be a great bonus, though.

> planning to get this wrapped up by this weekend if not sooner.

Excellent!

Thanks!

Martin
(Continue reading)

Permalink | Reply | 1 comment |
headers
whit | 3 Jan 2007 18:51
Picon

Re: Re: wicked update

Martin Aspeli wrote:
> whit wrote:
>> I'm pretty close to being ready to "merge" though I think that the 
>> actual merge may only be some snippets of zcml(and a few interface 
>> applications).
>
> The kind of merge we like :)
>
>> made some good progress today and tied up a few existing loose ends. 
>> wicked can now be turned on and off via the persistent component 
>> registry.  I also implemented a media wiki style registration.
>
> What is media wiki style registration?
>
basically, so you can choose [[linking]]  instead of ((linking)) for 
your site if you want to.  this was one of limi's requests.  To

>> All that is really left is to make a control panel(panel could 
>> probably wait though?).
>
> Have you had a look at plone.app.controlpanel? Formlib galore :)
>
> I'd say we can merge without a control panel but with sensible/safe 
> defaults. Having the control panel would be a great bonus, though.
>
the infrastructure is pretty much there.  I'm handling the registration 
of "options" as classes[1] that are registered as entry points[2].  The 
class has methods for doing all the local component registering and 
unregistering as well as some metadata about what the bundle of 
registrations do.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raphael Ritz | 4 Jan 2007 15:13
Picon
Favicon

plip 101 - batch and sort

Hi guys,

this is just to let you know that student of mine, Florian Kamm,
is implementing a solution for PLIP 101

   http://plone.org/products/plone/roadmap/101

  "Sortable tables need to be improved, the javascript needs to
   be cleaned up and if the table is part of a batch it should
   handle the whole batch, not only the visible part."

You can get the current code from

    http://plone.org/products/batchit

I know that this Plip isn't on our current agenda but still I thought
I just let you know. As it's AJAX-based it might make for another nice
use case in that context.

Florian and I are willing to donate the code to the foundation and
to do the integration work should the team decide to go for it.

Let me know what you all think.

	Raphael
Permalink | Reply | 1 comment |
headers
Martin Aspeli | 4 Jan 2007 23:34
Picon
Gravatar

Re: plip 101 - batch and sort

Raphael Ritz wrote:
> Hi guys,
> 
> this is just to let you know that student of mine, Florian Kamm,
> is implementing a solution for PLIP 101
> 
>   http://plone.org/products/plone/roadmap/101
> 
>  "Sortable tables need to be improved, the javascript needs to
>   be cleaned up and if the table is part of a batch it should
>   handle the whole batch, not only the visible part."
> 
> You can get the current code from
> 
>    http://plone.org/products/batchit
> 
> I know that this Plip isn't on our current agenda but still I thought
> I just let you know. As it's AJAX-based it might make for another nice
> use case in that context.
> 
> Florian and I are willing to donate the code to the foundation and
> to do the integration work should the team decide to go for it.
> 
> Let me know what you all think.

I think this sounds interesting, and it's certainly functionality we 
would want. I wouldn't have any time to dedicate to it personally, 
though, and I know we have a lot of work on existing PLIPs.

It wouldn't bother me much if we didn't land this before 3.5 in light of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raphael Ritz | 5 Jan 2007 10:32
Picon
Favicon

Re: plip 101 - batch and sort

whit schrieb:

Hi Whit,

> how far along is your student

so far that you can get a Product from the URL mentioned
below to install this into a Plone-2.5.x site.
And it works ;-)

> and are they using kss to do this?

Yes.

> very 
> interested, was looking at tackling this this week.
>

so maybe you want to take a look there first.

Raphael

PS: for the impatient ;-)

The kss declarations are:

table.listing th:click {
     evt-click-preventdefault: True;
     action-server: manipulateBatch;
     manipulateBatch-field: nodeAttr("id");
(Continue reading)

Permalink | Reply | 6 comments |
headers
whit | 5 Jan 2007 11:10
Picon

wicked integration w/ plone 3

initially seems to be working using ATDocument unaltered(no special 
fields, no special content). 

I need to do a bit more testing, but wicked's tests run against ATCT 
without issue(in 3 flavors: wicked for all AT text fields, just primary 
textfield for newsitem, event and document and document only). 

see: 
http://svn.plone.org/svn/collective/wicked/lib/wicked/trunk/wicked/plone/

what fields get the wicked treatment is current determined in zcml(the 
zcml marks the specific fields to enact behavior therefore has to happen 
act configuration time rather than via persistent component). 

This provides some flexibility, but later we may want to mark the fields 
more explicitly(say, in the content class itself).   I chose the 3 
configuration options above mainly to cess out possible problems; I 
imagine we would decide on a configuration to ship plone with, and then 
the intrepid could twiddle the zcml if they so desired. 

Probably document-only.zcml would be the best default.

that leaves the controlpanel...which is about a third done...

night,

-w
Attachment (whit.vcf): text/x-vcard, 317 bytes
(Continue reading)

Permalink | Reply | 30 comments |
headers
Martin Aspeli | 5 Jan 2007 11:33
Picon
Gravatar

Re: wicked integration w/ plone 3

Whit,

You rock. :)

Will skim through the code today, but I'm very optimistic that we
should merge during the weekend.

I don't think having TTW configuration for which *fields* should get
the Wicked treatment makes much sense (too low level). Having a way to
turn the behaviour on/off and possibly change the syntax choice makes
sense.

But then what happens with documents using the "old" syntax? Maybe it
can be a multi-select rather than single select, so you get:

Wicked syntax:

 [x] Wicked style ((words))
 [ ] MediaWiki style [[words]]

And if you untick both, you get no wicked at all?

In any case, I say we enable by default for documents and people can
turn on for other things if need be. A slightly more ambitious
configuration solution would be that you have some vocabulary
(probably a utility vocabulary with a small utility for each possible
content type) that marks which content types can support wiki syntax
(the exact fields to use may be properties of the utility or set in
ZCML somewhere), and then you get another multi-select:
(Continue reading)

Permalink | Reply | 28 comments |
headers
Raphael Ritz | 5 Jan 2007 14:20
Picon
Favicon

Re: wicked integration w/ plone 3

Martin Aspeli schrieb:

[..]

> I don't think having TTW configuration for which *fields* should get
> the Wicked treatment makes much sense (too low level). 

Agreed.

But in the long run it might very well make sense.

I like for instance the 'textfilter' approach and I could
imagine more functionality managed that way. I think in particular
of the way in which I currently support inline citations in CMFBib
via PortalTransforms which sucks in that it's not really a
trafo between different mime types but only fake ones.
Similar for 'safe-html' or 'html-captioned'.
Having these testfilter-based would be much nicer I think.

Having the possibility to configure TTW (ZMI or configlet)
which filters to apply for which fields - maybe even controled
by conditions (e.g., safe-html filtering is skipped for content
coming from trusted users to make up an example) could go a long
way.

[..]

> 
> Wicked types:
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Martin Aspeli | 5 Jan 2007 15:46
Picon
Gravatar

Re: Re: wicked integration w/ plone 3

Hi Raphael,

> > I don't think having TTW configuration for which *fields* should get
> > the Wicked treatment makes much sense (too low level).
>
> Agreed.
>
> But in the long run it might very well make sense.
>
> I like for instance the 'textfilter' approach and I could
> imagine more functionality managed that way. I think in particular
> of the way in which I currently support inline citations in CMFBib
> via PortalTransforms which sucks in that it's not really a
> trafo between different mime types but only fake ones.
> Similar for 'safe-html' or 'html-captioned'.
> Having these testfilter-based would be much nicer I think.
>
> Having the possibility to configure TTW (ZMI or configlet)
> which filters to apply for which fields - maybe even controled
> by conditions (e.g., safe-html filtering is skipped for content
> coming from trusted users to make up an example) could go a long
> way.

I agree, but I think this would have to take the form of a
well-defined Python configuration mechanism and a use-case specific UI
on top of that. That is, I don't think we'd ever want to expose the
user to something like:

Portal type: CMFBibDoc
(Continue reading)

Permalink | Reply | 1 comment |

Gmane