hello Maurizio, yes, I agree with you .. sorry for the confusion, I was speaking more in general when I talked about my fear of the cartridge to become bloated. Many people request different features, and sometimes it's better to leave them out (unlike your suggestion that will make it into the repository :-) )
thanks for the feedback! -- Wouter > Wouter, > > I agree with you, there should be better ways for adding layout to jsp > pages > then modelling. Walter's idea of using xslt is great: jsp pages can be > transformed, so adding layout to pages and adjusting the rendering of page > objects. > > However, table actions aren't "simple" actions with a particular layout. > They are conceptually different objects, that, differently from "simple" > actions, operate on the items listed in the table. As such, they should be > specified in the model and I just proposed a way to do this, by using two > tags. That's it. > > Cheers, > Maurizio > > -----Messaggio originale----- > Da: Wouter Zoons [mailto:[EMAIL PROTECTED] > Inviato: mercoledì 1 dicembre 2004 21.14 > A: 'Matthias Küspert'; 'Maurizio De Mattei' > Cc: 'andromda-user' > Oggetto: RE: R: [Andromda-user] RE: bpm4struts layout > suggestions/questions > > 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. > > 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. > > 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 > > Ideas ? > > -- Wouter > >> -----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
