Re: [Flashcoders] About OOP metodology
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
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. ___ 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
Re: [Flashcoders] About OOP metodology
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
RE: [Flashcoders] About OOP metodology
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. ___ 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] About OOP metodology
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
Re: [Flashcoders] About OOP metodology
I generally prefer loading external SWFs for this sort of thing. That way the individual form SWFs are not dependent on the master SWF. And you avoid library bloat. You could create a template that is a starting point for building individual forms. -Adam 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
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
RE: [Flashcoders] About OOP metodology
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
