Mailing List Archive: Zope: CMF

CMFActionIcons vs. new-style actions

Index | Next | Previous | View Threaded

jens at dataflake

Sep 13, 2008, 6:28 AM

Post #1 of 21 (1218 views)
Permalink

CMFActionIcons vs. new-style actions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today I was looking at the CMFActionIcons product and wondered about a
few things. First of all, there's no obvious way to enable the actions
and include the template snippets that pull them in. Editing the
main_template is needed. Secondly, the new-style actions already
define a property to store an expression for generating a icon path,
but it doesn't appear to be used anywhere yet.

Question: Wouldn't it make sense to enable the new action icons
functionality in the various templates to show icons if an expression
for an icon is provided, and completely retire the CMFActionIcons
product?

jens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjLv/AACgkQRAx5nvEhZLLeygCfbw/3TV02VHFczUW/MGKtSa+h
u7YAn2zw5mIWLkIa+214a53YOsTzLlJS
=cxAi
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 13, 2008, 6:45 AM

Post #2 of 21 (1183 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Today I was looking at the CMFActionIcons product and wondered about a
> few things. First of all, there's no obvious way to enable the actions
> and include the template snippets that pull them in. Editing the
> main_template is needed. Secondly, the new-style actions already
> define a property to store an expression for generating a icon path,
> but it doesn't appear to be used anywhere yet.
>
> Question: Wouldn't it make sense to enable the new action icons
> functionality in the various templates to show icons if an expression
> for an icon is provided, and completely retire the CMFActionIcons
> product?

+1 - CMFActionIcons is a bit of a nuisance these days. I never
understood why you'd need to separate the definition of the action (in
the ZMI or GS) from its icon.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Sep 13, 2008, 9:35 PM

Post #3 of 21 (1176 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Previously Martin Aspeli wrote:
> Jens Vagelpohl wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Today I was looking at the CMFActionIcons product and wondered about a
> > few things. First of all, there's no obvious way to enable the actions
> > and include the template snippets that pull them in. Editing the
> > main_template is needed. Secondly, the new-style actions already
> > define a property to store an expression for generating a icon path,
> > but it doesn't appear to be used anywhere yet.
> >
> > Question: Wouldn't it make sense to enable the new action icons
> > functionality in the various templates to show icons if an expression
> > for an icon is provided, and completely retire the CMFActionIcons
> > product?
>
> +1 - CMFActionIcons is a bit of a nuisance these days. I never
> understood why you'd need to separate the definition of the action (in
> the ZMI or GS) from its icon.

Easier customization - no need to let people touch the action itself?

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 14, 2008, 1:18 AM

Post #4 of 21 (1178 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 14, 2008, at 06:35 , Wichert Akkerman wrote:

> Previously Martin Aspeli wrote:
>> Jens Vagelpohl wrote:
>>> Question: Wouldn't it make sense to enable the new action icons
>>> functionality in the various templates to show icons if an
>>> expression
>>> for an icon is provided, and completely retire the CMFActionIcons
>>> product?
>>
>> +1 - CMFActionIcons is a bit of a nuisance these days. I never
>> understood why you'd need to separate the definition of the action
>> (in
>> the ZMI or GS) from its icon.
>
> Easier customization - no need to let people touch the action itself?

Just at the high price of maintaining a full separate Zope product.
That trade-off seems a bit lame.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjMyPMACgkQRAx5nvEhZLKmwgCfULE4/0dSmqPVdPo0NWRYypB4
Yx8AoJFGKJX7x6yImrRRsnSQFvHHZRMt
=GceZ
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie at begeistert

Sep 14, 2008, 2:25 AM

Post #5 of 21 (1173 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Am 13.09.2008 um 15:28 schrieb Jens Vagelpohl:

> Question: Wouldn't it make sense to enable the new action icons
> functionality in the various templates to show icons if an expression
> for an icon is provided, and completely retire the CMFActionIcons
> product?

+1 from me. This action icons would add a lot to the CMF if enabled by
default and ActionIcons doesn't provide any other functionality which
could justify a separate existence.

Charlie
--
Charlie Clark
Helmholtzstr. 20
D�sseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 14, 2008, 4:32 AM

Post #6 of 21 (1176 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Wichert Akkerman wrote:

> Easier customization - no need to let people touch the action itself?

You can change a property of an action easily enough with GS or in the
ZMI. So, a separate registry is more isolated, but it's also harder to
guess which portal_actionicons thing you need to add/modify to modify a
particular action. Looking in two places doesn't necessarily make it easier.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

hannosch at hannosch

Sep 15, 2008, 8:47 AM

Post #7 of 21 (1177 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Jens Vagelpohl wrote:
> Question: Wouldn't it make sense to enable the new action icons
> functionality in the various templates to show icons if an expression
> for an icon is provided, and completely retire the CMFActionIcons
> product?

+1

I already moved most of Plone trunk to use the icon expressions on the
actions and not rely on CMFActionIcons anymore.

CMFActionIcons is meanwhile superseded by the normal actions, so go
ahead and retire it.

Hanno

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 18, 2008, 12:52 AM

Post #8 of 21 (1160 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 13, 2008, at 15:28 , Jens Vagelpohl wrote:

> Question: Wouldn't it make sense to enable the new action icons
> functionality in the various templates to show icons if an expression
> for an icon is provided, and completely retire the CMFActionIcons
> product?

This has now landed, in several chunks because it turned out to be
more work and a larger change set than expected, on the CMF trunk.
Silly me thinking most of my work was done when Yuppie thoughtfully
added a icon URL expression property to the new-style actions ;-)

Additional work included...

- extend the "old-style" actions, those you see e.g. on a type
information "Actions" tab in the ZMI, to also have a field for an icon
URL expression

- extend the DCWorkflow Transition and Worklist classes, which store
the information for their own action directly on the class, to have an
icon URL expression field

- add a portal setting, also available through the "Reconfigure
portal" CMF screen, to switch the icons on or off globally.

- change the basic main_template in CMFDefault/skins/zpt_generic to
look for the global icon flag and icon data from the actions

- fix up some existing CMFActionIcons icons and search for a whole
bunch of additional icons

I'm not the greatest artist in the world, if anyone dislikes a
particular icon please feel free to replace it with something that
makes sense to a normal user. Just make sure it has a transparent
background.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjSCNMACgkQRAx5nvEhZLIF7wCdFFBqbko8L5ACgR1WZ9NzOox2
5fUAn3X8uo6AcJsBEzq9mOJbrQh0K+TA
=oW68
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Sep 18, 2008, 12:56 AM

Post #9 of 21 (1166 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Previously Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sep 13, 2008, at 15:28 , Jens Vagelpohl wrote:
>
> > Question: Wouldn't it make sense to enable the new action icons
> > functionality in the various templates to show icons if an expression
> > for an icon is provided, and completely retire the CMFActionIcons
> > product?
>
> This has now landed, in several chunks because it turned out to be
> more work and a larger change set than expected, on the CMF trunk.
> Silly me thinking most of my work was done when Yuppie thoughtfully
> added a icon URL expression property to the new-style actions ;-)
>
> Additional work included...
>
> - extend the "old-style" actions, those you see e.g. on a type
> information "Actions" tab in the ZMI, to also have a field for an icon
> URL expression
>
> - extend the DCWorkflow Transition and Worklist classes, which store
> the information for their own action directly on the class, to have an
> icon URL expression field
>
> - add a portal setting, also available through the "Reconfigure
> portal" CMF screen, to switch the icons on or off globally.
>
> - change the basic main_template in CMFDefault/skins/zpt_generic to
> look for the global icon flag and icon data from the actions
>
> - fix up some existing CMFActionIcons icons and search for a whole
> bunch of additional icons
>
> I'm not the greatest artist in the world, if anyone dislikes a
> particular icon please feel free to replace it with something that
> makes sense to a normal user. Just make sure it has a transparent
> background.

Are they png images? If not, can we please make them png so we can
easily customize them using alpha channels?

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 18, 2008, 1:00 AM

Post #10 of 21 (1165 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 18, 2008, at 09:56 , Wichert Akkerman wrote:
>> I'm not the greatest artist in the world, if anyone dislikes a
>> particular icon please feel free to replace it with something that
>> makes sense to a normal user. Just make sure it has a transparent
>> background.
>
> Are they png images? If not, can we please make them png so we can
> easily customize them using alpha channels?

Of course they are. I thought you were on the checkins list ;-)

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjSCrsACgkQRAx5nvEhZLLgcACfSLTBPP+RltwJdNOSH9HZBljS
cWQAn1kw9aI1dyLyrwVjyTZlYCnx8z3+
=1/A3
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Sep 18, 2008, 1:06 AM

Post #11 of 21 (1160 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Previously Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sep 18, 2008, at 09:56 , Wichert Akkerman wrote:
> >> I'm not the greatest artist in the world, if anyone dislikes a
> >> particular icon please feel free to replace it with something that
> >> makes sense to a normal user. Just make sure it has a transparent
> >> background.
> >
> > Are they png images? If not, can we please make them png so we can
> > easily customize them using alpha channels?
>
> Of course they are. I thought you were on the checkins list ;-)

I am, but I don't memorize all mails sent over it :)

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Sep 18, 2008, 1:06 AM

Post #12 of 21 (1160 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

y.2008 at wcm-solutions

Sep 18, 2008, 2:13 AM

Post #13 of 21 (1163 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Hi Jens!

Jens Vagelpohl wrote:
> This has now landed, in several chunks because it turned out to be
> more work and a larger change set than expected, on the CMF trunk.
> Silly me thinking most of my work was done when Yuppie thoughtfully
> added a icon URL expression property to the new-style actions ;-)

Sorry about that. The original plan was to get rid of old-style actions
completely, but I never finished that task.

> Additional work included...
>
> - extend the "old-style" actions, those you see e.g. on a type
> information "Actions" tab in the ZMI, to also have a field for an icon
> URL expression

That might have been the most pragmatic solution, but in the long run we
should not maintain two different Action machineries.

I personally prefer to move all type info Actions to the actions tool. I
can't see a need to specify separate 'view', 'edit' or 'metadata'
Actions for each content type. That just makes it necessary to maintain
a lot of redundant configuration data. In how many places did you have
to set "string:${portal_url}/edit_icon.png"?

Some Actions like 'download' should only be available for specific
portal types. That makes things a bit more complicated, but can be solved.

If people really want to maintain separate Actions for each type, we
should consider to make type infos containers for new-style Actions.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 18, 2008, 2:40 AM

Post #14 of 21 (1161 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 18, 2008, at 11:13 , yuppie wrote:

>> - extend the "old-style" actions, those you see e.g. on a type
>> information "Actions" tab in the ZMI, to also have a field for an
>> icon
>> URL expression
>
> That might have been the most pragmatic solution, but in the long
> run we
> should not maintain two different Action machineries.

You are totally right of course. Doing that wholesale switchover and
replacement simply wasn't something I could get done for 2.2.0. I
thought about that many times as I went through all the places that do
define actions. Actually there's not two, but three different
machineries in play when you consider the workflow actions, and those
workflow actions are the strangest because they don't use TAL
expressions but string replacement to expand the expression-style
fields.

> I personally prefer to move all type info Actions to the actions
> tool. I
> can't see a need to specify separate 'view', 'edit' or 'metadata'
> Actions for each content type. That just makes it necessary to
> maintain
> a lot of redundant configuration data. In how many places did you have
> to set "string:${portal_url}/edit_icon.png"?
>
> Some Actions like 'download' should only be available for specific
> portal types. That makes things a bit more complicated, but can be
> solved.
>
> If people really want to maintain separate Actions for each type, we
> should consider to make type infos containers for new-style Actions.

Yes, there's redundant information in many places. Collecting all
actions in the actions tool itself would be the cleanest way, but a
more manageable first step would be making type information objects
into action containers as you suggest. The same could be applied to
DCWorkflow Worklist and Transition definitions.

I have added a Launchpad "blueprint":

https://blueprints.launchpad.net/zope-cmf/+spec/unify-actions

Collecting our projects as blueprints has the advantage that there's a
single place to track all of them, with concise information about the
task and who's doing/reviewing it:

https://blueprints.launchpad.net/zope-cmf

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjSIgEACgkQRAx5nvEhZLLkLQCdEzmo0d0va5kM6XnsOfX/bjAx
ngQAoIgXB7Evu//jpFDtU7kCGf1czYNE
=TRp9
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Sep 18, 2008, 3:37 AM

Post #15 of 21 (1165 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Previously yuppie wrote:
> I personally prefer to move all type info Actions to the actions tool. I
> can't see a need to specify separate 'view', 'edit' or 'metadata'
> Actions for each content type. That just makes it necessary to maintain
> a lot of redundant configuration data. In how many places did you have
> to set "string:${portal_url}/edit_icon.png"?

Per-type edit and view actions are a very important customization point.
We should not make it harder for people to do that. Per-type actions are
very common in Plone, I'ld hate to loose them.

A good alternative might be to have a concept of action-overrides: a
set of actions that override or extend the global list of actions for
a specific context. That is something that I've wanted a few times and
could replace per-type actions.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

tseaver at palladion

Sep 18, 2008, 4:27 AM

Post #16 of 21 (1161 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jens Vagelpohl wrote:
>
> On Sep 13, 2008, at 15:28 , Jens Vagelpohl wrote:
>
>> Question: Wouldn't it make sense to enable the new action icons
>> functionality in the various templates to show icons if an expression
>> for an icon is provided, and completely retire the CMFActionIcons
>> product?
>
> This has now landed, in several chunks because it turned out to be
> more work and a larger change set than expected, on the CMF trunk.
> Silly me thinking most of my work was done when Yuppie thoughtfully
> added a icon URL expression property to the new-style actions ;-)
>
> Additional work included...
>
> - extend the "old-style" actions, those you see e.g. on a type
> information "Actions" tab in the ZMI, to also have a field for an icon
> URL expression
>
> - extend the DCWorkflow Transition and Worklist classes, which store
> the information for their own action directly on the class, to have an
> icon URL expression field
>
> - add a portal setting, also available through the "Reconfigure
> portal" CMF screen, to switch the icons on or off globally.
>
> - change the basic main_template in CMFDefault/skins/zpt_generic to
> look for the global icon flag and icon data from the actions
>
> - fix up some existing CMFActionIcons icons and search for a whole
> bunch of additional icons
>
> I'm not the greatest artist in the world, if anyone dislikes a
> particular icon please feel free to replace it with something that
> makes sense to a normal user. Just make sure it has a transparent
> background.

Great! Thanks for the work!

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver[at]palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI0jsi+gerLs4ltQ4RAihDAJ0WUf/AStk+1CuBerC1LwslScPIOQCgs034
Ivd/7S7wWrdbkq105hFaVg4=
=LOcM
-----END PGP SIGNATURE-----

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 18, 2008, 5:03 AM

Post #17 of 21 (1163 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Hi Wichert!

Wichert Akkerman wrote:
> Previously yuppie wrote:
>> I personally prefer to move all type info Actions to the actions tool. I
>> can't see a need to specify separate 'view', 'edit' or 'metadata'
>> Actions for each content type. That just makes it necessary to maintain
>> a lot of redundant configuration data. In how many places did you have
>> to set "string:${portal_url}/edit_icon.png"?
>
> Per-type edit and view actions are a very important customization point.
> We should not make it harder for people to do that. Per-type actions are
> very common in Plone, I'ld hate to loose them.

Can you point me to some examples? Looking at the default CMFPlone
profile I couldn't find any. Repeated definitions for 'view', 'edit',
'download', 'external_edit', 'history' or 'references' Actions look
quite redundant to me.

Note that a don't propose to give all types the same set of Actions. I
just propose that using Actions with the same ID means using the same
settings. And the target of the Action can be set per type by modifying
the aliases.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 18, 2008, 6:17 AM

Post #18 of 21 (1167 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

yuppie-4 wrote:
>
> Hi Wichert!
>
>
> Wichert Akkerman wrote:
>> Previously yuppie wrote:
>>> I personally prefer to move all type info Actions to the actions tool. I
>>> can't see a need to specify separate 'view', 'edit' or 'metadata'
>>> Actions for each content type. That just makes it necessary to maintain
>>> a lot of redundant configuration data. In how many places did you have
>>> to set "string:${portal_url}/edit_icon.png"?
>>
>> Per-type edit and view actions are a very important customization point.
>> We should not make it harder for people to do that. Per-type actions are
>> very common in Plone, I'ld hate to loose them.
>
> Can you point me to some examples? Looking at the default CMFPlone
> profile I couldn't find any. Repeated definitions for 'view', 'edit',
> 'download', 'external_edit', 'history' or 'references' Actions look
> quite redundant to me.
>

I would be extremely uncomfortable with losing the ability to do:

- Per-type definition of *which* actions are shown in a given category
- Per-type definition of *what* those actions go to

Actions in the FTI usually result in tabs in Plone. Custom types often have
additional tabs, or make /edit, say, point to another view.

I think there's a case for saying that there's always a 'view' and an 'edit'
action that go to /view and /edit and you use method aliases to point them
at different templates. However, we need the ability to change permissions,
TALES conditions, labels and so on per-type.

Reducing repetition would be good, of course. We certainly have conventions
that apply to most (but not all) types. If there was a way to make per-type
actions optional as overrides/additional items (including the ability to
turn off an action inherited from globals) that may be good.

Martin
--
View this message in context: http://www.nabble.com/CMFActionIcons-vs.-new-style-actions-tp19470530p19552670.html
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 18, 2008, 7:04 AM

Post #19 of 21 (1161 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

Hi Martin!

Martin Aspeli wrote:
> yuppie-4 wrote:
>> Wichert Akkerman wrote:
>>> Previously yuppie wrote:
>>>> I personally prefer to move all type info Actions to the actions tool. I
>>>> can't see a need to specify separate 'view', 'edit' or 'metadata'
>>>> Actions for each content type. That just makes it necessary to maintain
>>>> a lot of redundant configuration data. In how many places did you have
>>>> to set "string:${portal_url}/edit_icon.png"?
>>> Per-type edit and view actions are a very important customization point.
>>> We should not make it harder for people to do that. Per-type actions are
>>> very common in Plone, I'ld hate to loose them.
>> Can you point me to some examples? Looking at the default CMFPlone
>> profile I couldn't find any. Repeated definitions for 'view', 'edit',
>> 'download', 'external_edit', 'history' or 'references' Actions look
>> quite redundant to me.
>>
>
> I would be extremely uncomfortable with losing the ability to do:
>
> - Per-type definition of *which* actions are shown in a given category

Sure.

> - Per-type definition of *what* those actions go to

As you mention below, method aliases can be used for that.

> I think there's a case for saying that there's always a 'view' and an 'edit'
> action that go to /view and /edit and you use method aliases to point them
> at different templates. However, we need the ability to change permissions,
> TALES conditions, labels and so on per-type.

How often do you need that ability? Can we make that a bit harder if we
can get other benefits in return?

> Reducing repetition would be good, of course. We certainly have conventions
> that apply to most (but not all) types. If there was a way to make per-type
> actions optional as overrides/additional items (including the ability to
> turn off an action inherited from globals) that may be good.

The solution I have in mind is maintaining a simple set of Action IDs
inside a type info property. All Actions are stored in one place, but
availability is looked up in the type infos.

If you need a different edit action, you create a new one with a new ID.
And add its ID to the type infos that should use it.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

tseaver at palladion

Sep 18, 2008, 8:06 AM

Post #20 of 21 (1160 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> Hi Martin!
>
>
> Martin Aspeli wrote:
>> yuppie-4 wrote:
>>> Wichert Akkerman wrote:
>>>> Previously yuppie wrote:
>>>>> I personally prefer to move all type info Actions to the actions tool. I
>>>>> can't see a need to specify separate 'view', 'edit' or 'metadata'
>>>>> Actions for each content type. That just makes it necessary to maintain
>>>>> a lot of redundant configuration data. In how many places did you have
>>>>> to set "string:${portal_url}/edit_icon.png"?
>>>> Per-type edit and view actions are a very important customization point.
>>>> We should not make it harder for people to do that. Per-type actions are
>>>> very common in Plone, I'ld hate to loose them.
>>> Can you point me to some examples? Looking at the default CMFPlone
>>> profile I couldn't find any. Repeated definitions for 'view', 'edit',
>>> 'download', 'external_edit', 'history' or 'references' Actions look
>>> quite redundant to me.
>>>
>> I would be extremely uncomfortable with losing the ability to do:
>>
>> - Per-type definition of *which* actions are shown in a given category
>
> Sure.
>
>> - Per-type definition of *what* those actions go to
>
> As you mention below, method aliases can be used for that.
>
>> I think there's a case for saying that there's always a 'view' and an 'edit'
>> action that go to /view and /edit and you use method aliases to point them
>> at different templates. However, we need the ability to change permissions,
>> TALES conditions, labels and so on per-type.
>
> How often do you need that ability? Can we make that a bit harder if we
> can get other benefits in return?
>
>> Reducing repetition would be good, of course. We certainly have conventions
>> that apply to most (but not all) types. If there was a way to make per-type
>> actions optional as overrides/additional items (including the ability to
>> turn off an action inherited from globals) that may be good.
>
> The solution I have in mind is maintaining a simple set of Action IDs
> inside a type info property. All Actions are stored in one place, but
> availability is looked up in the type infos.
>
> If you need a different edit action, you create a new one with a new ID.
> And add its ID to the type infos that should use it.

We could just use the aliases for that: essentially, they would be the
list of "valid" object actions for the object.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver[at]palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI0m5Y+gerLs4ltQ4RAu2RAKDCKAuSHdnkIC+5qjptL5slo0byrgCfVkSw
omCTYtxKVO0MHF3b3RMdVWU=
=EvH7
-----END PGP SIGNATURE-----

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

dieter at handshake

Sep 18, 2008, 9:40 AM

Post #21 of 21 (1166 views)
Permalink

Re: CMFActionIcons vs. new-style actions [In reply to]

yuppie wrote at 2008-9-18 11:13 +0200:
> ...
>I personally prefer to move all type info Actions to the actions tool. I
>can't see a need to specify separate 'view', 'edit' or 'metadata'
>Actions for each content type. That just makes it necessary to maintain
>a lot of redundant configuration data. In how many places did you have
>to set "string:${portal_url}/edit_icon.png"?

Not all of my content types have all actions from "view/edit/metadata".
Some of my content types have two different "view" actions (one
which shows the metadata and one which shows the content).

--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com