Another thing I love about this approach - (abstract flash file, layout, content and config dictated by XML) is that if you want to database-ize it, you can in the future - you would have a script update the XML from the database, and you could create an interface in Flash or HTML to update the database from an admin/content creation perspective. And because the flash file draws from the XML not directly from the database, it's portable if you want to move it elsewhere.
Jason Merrill Bank of America Learning & Organization Effectiveness - Technology Solutions >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:flashcoders- >>[EMAIL PROTECTED] On Behalf Of Adrian Park >>Sent: Wednesday, July 26, 2006 4:39 AM >>To: Flashcoders mailing list >>Subject: Re: [Flashcoders] About OOP metodology >> >>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. >>> > > > _______________________________________________ >>> > > > [email protected] >>> > > > 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 >>> > > > >>> > > _______________________________________________ >>> > > [email protected] >>> > > 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 >>> > > >>> > >>> > _______________________________________________ >>> > [email protected] >>> > 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 >>> > >>> _______________________________________________ >>> [email protected] >>> 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 >>> >>_______________________________________________ >>[email protected] >>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 _______________________________________________ [email protected] 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
