> [MK] I see your point, but even if it's slow - it's doing its work much
> more faster than anybody would code it ;-) And manually updating JSPs
> after model changes costs time too (and may cause new errors). As you
> may remember: I'm not a big fan of editing generated files ;-)
>

yeah :-) wish we could have met at the conference, be sure to be present
next time :-)

> The reasons I think we need some support for
>
>   1. defining multiple actions coming out of a collection-table
>   2. defining action-links as images
>
>   are:
>       - these are very useful GUI-patterns
>       - these are widely used GUI-patterns
>

agreed .. the reasons they're not in yet are

1. big todo list
2. just changed employer .. a lot of work, a lot of expectations
3. endless loop problem in bpm, this one is very tricky
4. andromda 3.0 final needs to be released (first 3.0M3, next a period of
bugfixing and finally the release)


> (1) could be achieved by merging outgoing transitions by
>     collection-parameters - OK, this *is* some logic which may slow down
>     but in my eyes it's worth it.
>
>     This would be easy to use: just model two actions with parameters
>     from the same collection and magically they appear in the same
>     table.
>
>     Problem: howto define the cell-order in a row? Maybe we need a
>     tagged-value here?
>     BTW: how is this defined in the current version?
>

I need to think about this .. I want to make sure to avoid ambiguous cases


> (2) could be easily implemented by adding the type 'image' to
>     @andromda.struts.action.type - I see no performance impact
>     here - it's just generating other HTML- and/or CSS-tags around the
>     action.
>

yeah sure .. no problem here


> [MK] 'Merging' something at runtime into the templates sounds good - but
> how does this work? Do you have an example?
>

no :-) but did you read the email from Walter ? exciting idea, no ?



> [MK] Yes! Separate layout and logic! Layout is *only* defined via CSS
> and resource-files!
>
> So:
>
> - we are generating GUIs with bpm4struts - so some GUI-dependent
>   information *must* be stored in the model as hints for the generator.
>

yes

> - we're *not* defining layout in the model:
>
>   1. Having multiple actions with parameters from the same collection
>      IMHO is a process-logic thing - ergo it belongs into the model.
>

agreed .. this is perfectly valid

>   2. Having a action tagged as 'image' is no layout - it's just
>      a action-type like 'form' or 'hyperlink'.
>

indeed, I agree here too

> I agree: adding generator features (especially if they introduce new
> tagged-values and/or slow down the generation process) should be done
> with care, but in this case I think it's really worth it.
>

for these two specific items I agree .. but I have also people asking for
tagged values for positioning fields in a grid using coordinates, or
having tables in tabs etc.. in the meantime I need to make sure
combination keep working too

I like to make the analogy with a powerful car .. I regular car, having
130 horsepower is quite powerful yet easy to control, and when in a
competition could very well come out as a winner

a sportscar having 450 horsepower does not neccesarily beat the one with
130 hp., it depends on who's driving because it's too much to control for
most people

it's the same with bpm4struts and feature .. I have a very strong feeling
that adding more features does not always mean more efficient development,
I'm even sure of it because it's what I experience at work, and I think I
can consider myself an advanced bpm4struts user :-)



> Also I cannot see that it will break some existent feature, nor will it
> make modeling more complicated.
>
> So, to answer your question: currently I see no better way. Also I
> cannot see how the merging of XML-files at generator-runtime could help
> here - could you explain that a bit more detailed?
>

allow me to refer once more to today's email from Walter .. he explained
it well

> TIA,
> Matthias
>

you're welcome

-- Wouter



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Andromda-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-user

Reply via email to