Hi Wouter, On Wed, 2004-12-01 at 21:14, Wouter Zoons wrote: > Hello, > > To be honest to more I think about it, the more I feel I should not put this > stuff in the cartridge. I know it's convenient sometimes to have as much as > possible generated, but actually it's easier to manually update the JSP page > than to use those tagged values, trust me .. Another thing is performance, > bpm4struts is the slowest of all cartridges because it contains so much > logic and because it checks so many validation constraints .. I prefer to > not bloat the cartridge too much and have something which is a little more > lighter. > [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 ;-)
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 (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? (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. > I have had some good feedback on the www.openarchitecture.de conference and > perhaps there are alternative ways of specifying layout and style on > individual pages. One such example would be to have the cartridge look for > an (optional) XML file describing he layout of the page and merging that in > at runtime with the template .. that way you can have the cartridge generate > different code for each separate page. > [MK] 'Merging' something at runtime into the templates sounds good - but how does this work? Do you have an example? > Don't you guys feel too that there must be better ways to add layout to your > generated pages ? Don't forget that UML activity graphs are more suitable > for process logic (struts-config.xml etc..) and like said before: not for > style and layout > [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. - 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. 2. Having a action tagged as 'image' is no layout - it's just a action-type like 'form' or 'hyperlink'. 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. 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? TIA, Matthias > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:andromda-user- > > [EMAIL PROTECTED] On Behalf Of Matthias Küspert > > Sent: Tuesday, November 30, 2004 3:42 PM > > To: Maurizio De Mattei > > Cc: andromda-user > > Subject: Re: R: [Andromda-user] RE: bpm4struts layout > > suggestions/questions > > > > Hi Maurizio, > > > > sounds good, however, I'm not deep into bpm4struts - so you'll have to > > wait for Wouter. > > > > The only thing I'm not shure about is if these features will bring too > > much layout information into the model. I.e.: IMHO the name of the > > resource should *not* be in the model. A name should be generated and > > the file-name should come from a resource properties-file (so resources > > can be localized). > > > > Cheers, > > Matthias > > > > > > On Mon, 2004-11-29 at 11:32, Maurizio De Mattei wrote: > > > Hi Wouter, Hi Matthias, > > > > > > I have elaborated a little the idea of multiple actions in table rows > > and I > > > have some ideas about them. > > > Consider a page with several items listed in a table (I'm thinking to a > > > static table where values cannot be modified by users). Here we usually > > need > > > two types of actions: simple actions and table actions. > > > Simple actions are not related to the items listed in the table; for > > > instance, the action for creating a new item is a simple action. Often > > > simple actions have no parameters; other times simple actions are > > connected > > > to a form and their parameters are the posted form fields. > > > Table actions, on the contrary, are used to perform operations on the > > items > > > listed in the table, such as deleting an item or editing its attributes. > > So, > > > table actions are rendered inside the table, on the same row of the > > referred > > > item. Table actions can have one or more parameters and, most important, > > > their values are taken from cells of the row in which they are placed. > > For > > > instance, the delete item action could have one parameter named id. The > > > parameter value of the action rendered in row #3 is the value of the id > > cell > > > of row #3. > > > Actions, either simple either table, can be rendered in a jsp page as > > > buttons, links or images. > > > Something similar to the following tags could be used to implement this > > > model: > > > 1. an action-level tag to define the type of the action (simple or > > table) > > > 2. an action-level tag to define the action rendering; possible values > > are > > > button, link and image. In the third case the tag value could contain > > the > > > name of an image resource > > > in addition, for table actions: > > > 3. an action-level tag to define the name of the table column where the > > > action have to be rendered > > > 4. a parameter-level tag to define the column of the table the value of > > the > > > parameter should be taken from. > > > What do you think of these ideas? > > > Maurizio > > > > > > -----Messaggio originale----- > > > Da: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] conto di Wouter > > Zoons > > > Inviato: giovedì 25 novembre 2004 22.28 > > > A: 'Matthias Küspert' > > > Cc: 'andromda-user' > > > Oggetto: [Andromda-user] RE: bpm4struts layout suggestions/questions > > > > > > > Hi Wouter, > > > > > > > > I toyed around with my layout (thanks for your changes :-) and it's > > > > really flexible now. However, I have some new suggestions/questions: > > > > > > > > 1. div-tags for the following elements: > > > > > > > > - the input-elements of action-forms > > > > use the parameter-name? > > > > > > > [WZ> ] I guess we could do that, and add it in the jsp page CSS > > > > > > > - the submit-elements of the action-form > > > > use the action-name? > > > > > > > [WZ> ] yup > > > > > > > - the table-headers of the tables for incoming collections > > > > use the parameter-name? > > > > > > > [WZ> ] that's trickier because it's the displaytag library that is > > rendering > > > this stuff, I'll have to look into that > > > > > > > - the table-cells of the tables for incoming collections > > > > use the parameter name? > > > > > > > [WZ> ] really ? them too ? > > > > > > > We can give the table-* elements similar names because cells and > > > > headers can be separated vi td and th :-) > > > > > > > [WZ> ] I guess so ... okay sounds good > > > > > > > > > > > 2. remove the form around the tables for incoming collections > > > > > > > > Why is this form there? There's no submit in it, everything is done > > via > > > > links. The other day you mentioned that it's experimental ... what was > > > > the experiment? > > > > > > > [WZ> ] the 'experiment' is still ongoing .. I was playing with the idea > > that > > > cells could be updated in the table iself, but I think it's too much > > because > > > it will open up a set of possibilities that would be too complicated to > > > handle for the user .. I'm still working on that > > > > > > > > > > > > > > 3. calling multiple actions from a row in the tables for incoming > > > > collections > > > > > > > > Background: I want to show all entries with their names as link to a > > > > 'edit' action - no problem so far. Now I want to (1) add an image > > which > > > > (2) links to a 'delete' action for this entry - how can I model that? > > > > > > > > 1. There should be some values like 'image' and 'image-link' for the > > > > @andromda.struts.view.field.type > > > > tagged value. The image-resource could be defined via the > > > > action- and parameter-name in the application- > > resources.properties. > > > > > > > [WZ> ] have to think about that one, do you have an example ? > > > > > > > 2. I think it's sufficient if the delete-action carries at least one > > > > parameter which links to the table - bpm4struts then should > > > > collect all actions which have parameters linked to a table and > > > > include them into the table which is generated for the > > collection. > > > > > > > > ==> An action which has a collection-element parameter is always > > > > called from a table! Agree? > > > > > > > [WZ> ] no, you will have to set the 'tablelink' tagged value too .. > > please > > > note that the table columns are not parameters but simply properties > > entered > > > in a tagged value .. this makes it extra difficult to keep the model > > > syntactically correct: it should be possible to ignore tagged values > > > alltogether and still have code correctly generated > > > > > > > > > > I'm not very deep into bpm4struts internals - just an idea - what do > > you > > > > think? Does it make sense? > > > > > > > [WZ> ] yeah, this is valuable feedback .. could you file these as > > seperately > > > JIRA issues please ? the ones that are easy to do are likely to get done > > > quickly :-) > > > > > > > > > > TIA, > > > > Matthias > > > > > > [WZ> ] thanks again Matthias! > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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