expression or execute

[pmuir]

Hi

If you are using Seam with JBPM you end up with different syntax for executing actions uising EL:

Seam's pages.xml

<page>
 <action execute="#{foo.bar}" />
</page>

Seam's components.xml

<event>
 <action execute="#{foo.bar}" />
</event>

(actually currently its

components.xml

<event>
 <action expression="#{foo.bar}" />
</event>

but we are planning to deprecate this)

.jpdl.xml

<action expression="#{foo.bar}"/>

We (Seam dev) feel that execute is a better word as expression is what it is, whilst execute is what it does. In particular you can use expressions inside other attributes (e.g. condition="#{foo.isBar}" or actor-id="#{foo.actor}").

But I also think consistency is very important, so we am hoping that we can get execute as an alias to expression available in JPDL (best would be to deprecate expression I think). What do you guys think? A possibility?

http://jira.jboss.com/jira/browse/JBSEAM-1775

[kukeltje]

nice topic, since more and more attributes in jdpl can contain 'expressions' (the subprocessname being the latest)

I do not see any objections to aliasing it and (making expression an alias of execute) and logging a warning about deprecation. But... Tom has the final say in it.

and if we are dicussing consistency and reuse, lets
- bring the identity module of jbpm in line with the one of the portal BUT not make jBPM dependend on the portal (sol it should be a separate project or under JBossSSO)
- Bring the frameworks used by projects in line (JSF, Flex, GWT)
- ....

:-D

[tom.baeyens]

alias is possible. deprecation is not good imo.

the hardest part is not to support the parsing, but making sure that the docs are a bit in sync and coherent.

[pmuir]

Why do you not like deprecation? Because you prefer expression to execute? Or because of keeping the language the same? Or...?

[tom.baeyens]

i don't want to break current processes

[pmuir]

I don't see why deprecation would break anything. The attribute would still work and as we are agreed on an alias wouldn't mean a code change (although it could, as Ronald suggested, print out a warning) - the difference would just be in the docs i.e.

expression - a Unified EL expression (deprecated, use execute)
execute - a Unified EL expression

[kukeltje]

Yes Tom, deprecation != removing :-P

[tom.baeyens]

you're right. deprecating is more clear to the user what they should do.

and indeed ronald, it's the removing for which i was afraid. if we get to it, we deprecate the expression attribute, but we'll probably never remove it.

[kukeltje]

If we never intend to remove it, we should not really deprecate it (either by documenting it and/or logging a warning), just leave it in as an alias to execute.

[gavin.king]

Deprecate it and then remove it in the next major version.

[pmuir]

http://jira.jboss.com/jira/browse/JBPM-1054