Ricardo, I just read you most recent post where you mention that the design of inputs could change on a form by form basis. How much difference do you anticipate there'll be? Do you think you could get away with using components and then specifying style attributes such as size, colour and text attributes in the XML or will the styling be heavily customised for each form?
I've had a lot of success abstracting all this type of stuff into an XML configuration file as described in my previous message but I appreciate that sometimes the level of customisation required (different brands, different campaign themes e.t.c) makes this level of abstraction very difficult. I think it has to be accepted - by the client as much as anyone else - that the more customisation there is from form to form, the less the update process can be streamlined. I'm blabbering on now so I'll back off! A. On 7/26/06, Adrian Park <[EMAIL PROTECTED]> wrote:
The approach I'd take would be to use an XML configuration file to work out what inputs are needed and then create all the widgets from the library. This way, all you need to modify for each deployment is the XML configuration file. You could then also add attributes to the XML to flag things like whether the input of a particular widget should be validated or not, what url the form data should be submitted to and other such enhancements. Also, if you're worried about layout of different forms, you could add _x and _y attributes to the XML so you can simply tweak the layout on a form by form basis. This may mean some extra work up front but, in my experience, it saves a lot of blood sweat and tears down the line! If it's reasonable to assume the forms will all use a fairly standard set of widgets (text fields, combo boxes, radios, check boxes e.t.c) I'm not sure library bloat is going to be that much of a risk? Obviously, with this approach you would ideally be able to make assumptions about the full selection of form widgets you'll need in future but, equally, if it is built properly in the first place you should be able to add new types of input quickly and easily in future. HTH Adrian On 7/26/06, Ricardo Sánchez < [EMAIL PROTECTED] > wrote: > > Still not sure what to do. > > My doubt is more related to the change in the appearenace, number and > type > of fields in a form from one project to another. > > Should I make a different swf with a form for each project and change > the > class every time? (whatever pattern I use, mvc...) > Should I make a swf for each field and attach by code the ones I need > for > each project...? > > Do my questions make sense? > > On 6/30/06, Bernard Visscher < [EMAIL PROTECTED]> wrote: > > > > I think you could do this the MVC way > > ( http://en.wikipedia.org/wiki/Model_view_controller ) > > The only thing that really changes is your view, the model and the > > controller are almost the same. > > You could even write a model, controller and view which holds all > fields > > and > > logic that returns in all the forms. > > Then you extend those to meet the needs for this particular form. > > > > This is the same way edibol as wrote I see now... Quote: "You could > even > > abstract the technical logic from the UI completely and write > > communicators/controllers that respond to events fired from the ui > > (movieclips)." > > > > > > Greetz, > > > > Bernard > > > > > -----Oorspronkelijk bericht----- > > > Van: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] ] Namens elibol > > > Verzonden: vrijdag 30 juni 2006 17:06 > > > Aan: Flashcoders mailing list > > > Onderwerp: Re: [Flashcoders] About OOP metodology > > > > > > Try a compositional approach. You might design a set of > > > classes that reference movieclips and delegate events to the > > > class; this would be contrary to extending movieclips. This > > > way you can design movieclips specific to the site and design > > > the code specific to the logic. > > > > > > You could even abstract the technical logic from the UI > > > completely and write communicators/controllers that respond > > > to events fired from the ui (movieclips). > > > > > > M. > > > > > > On 6/30/06, Ricardo Sánchez < [EMAIL PROTECTED]> wrote: > > > > > > > > I've just started to work in a big internet communication > > > agency. We > > > > have to make 2 or 3 microsites every week. Each of which > > > uses a very > > > > similar form to get user data. > > > > > > > > All that changes from one to another is a couple of fields and the > > > > look of it. > > > > > > > > My question is: What's the best way to implement a > > > re-usable class for > > > > this kind of work? Should I make a movieclip with all the > > > fields and a > > > > class binded to it and modify the clip everytime I re-use it? Or > > > > should I make a class that loads different clips from the library? > > > > > > > > Do I explain myself? > > > > > > > > Thanks. > > > > _______________________________________________ > > > > Flashcoders@chattyfig.figleaf.com > > > > To change your subscription options or search the archive: > > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > > > Brought to you by Fig Leaf Software > > > > Premier Authorized Adobe Consulting and Training > > > > http://www.figleaf.com http://training.figleaf.com > > > > > > > _______________________________________________ > > > Flashcoders@chattyfig.figleaf.com > > > To change your subscription options or search the archive: > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > Brought to you by Fig Leaf Software > > > Premier Authorized Adobe Consulting and Training > > > http://www.figleaf.com http://training.figleaf.com > > > > > > > _______________________________________________ > > Flashcoders@chattyfig.figleaf.com > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > _______________________________________________ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com >
_______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
