Yes, thanks for the
insight.
I pretty much do the same thing
you do for POC purpose. I guess your UI guy is not typically responsible for
wiring up the UI to communicate with the server-side, where in our case he/she
is. After your definition, I do consider myself somewhat of a glue-guy, but as
quite as you suggest... something to think about. Thanks for
sharing.
Love the app as well
:)
Dimitrios "Jimmy" Gianninas
RIA Developer
Optimal Payments Inc.
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes
Sent: Thursday, August 25, 2005 8:14 PM
To: [email protected]
Subject: Re: [flexcoders] Cairngorm Development Cycle
This could be a long reply, so get comfortable.
I've found in FLEX, a lot of the mundane tasks are visuals, meaning "hmm does this color work, yes, cool" or "I need to come up with a structure here that is more fluid then traditional datagrid insert/update/delete aspects".
Take for example this: http://www.mossyblog.com/archives/519.cfm
Inside my "Sneak peak", I basically have a screen comprising of:
1x FilterPod (it can be interchangeable, in that if there is 1 tier, its a simple list, but if its many its a tree).
1x Calendar Pod
1x Inbox View
1x Custom AppWindow/AppPanel (more on that later)
1x Custom Initialize Window
1x Popup Wizard style window
etc..
Now In this example It was a solo thing, but if i were to hand this concept again to fellow team members, i would of given the UI guy/gal enough work to be able to carry on independent of the server-side person.
Meaning:
Task 1: build a splash screen, that takes an array of text that shows whats being loaded. I also want it to feed of a shared property (ie ModelLocator) to keep track of state, in that if state changes, put in some in line logic that updates visuals.
Task 2: build a Calendar Pod, that mimics Windows O/S "Calendar" within taskbar (ie dbl click on your windows time - for those who have windows). So when a user updates the year or month, the calendar control updates and same goes for calendar itself). On top of that, I want you to make sure the Calendar pod dispatches an event saying "Somethings changed" (ie dispatchEvent onDateChange() ) I also want you to provide a way to set selectedDate:Date for this pod, which also updates accordingly.
The list could go on..
Then for the serverside, i'd inform them that i need coldfusion to be work as if the UI is either HTML or FLASH or SOAP, in that don't give two hoots about how it comes together visually, just stipulate what you need in terms of arguments to a various services within and i'll make sure the uis adhere to that.
Now the "glue" guy/gal is the person that knows how to slot everything together, meaning "I want to fire xyz commands in sequence to show the initialization screen, in that i want to :
- test to see if the gateway is still there
- initialize security (ie ask cfmx singelton style request, is security model instantiated, if not do so )
- perform security handshake and wait for a result (ie log me in via my ActiveDirectory and see if have access to this flex app)
- grab my InboxFilter dataprovider (ie ask serverside for my inbox filters saved remotely)
- once i have my inbox filters, select my default and get all invoices pertaining to that filter, selectedDate and my profile
- now show the actual application if all passes ok.
Which I then switch from splashscreen child to mainchild,
Now in mainchild i basically layout all the UI ingredients I asked my UI guy/gal to create in an orderly way. I then setup various addlisteners, bindings etc to the api calls (ie if calenderpod updates date, update my Inboxfilter to reflect that date change etc)
Basically there are 4 "tiers" you can approach this with:
- Gluer / Architect
- UI
- Serverside
- DBA
On small apps this is a no brainer, but on much larger apps the segregation can be helpful but also can be a bottle neck if not carefully orchestrated. So that's why specification and planning is a crucial component of the "gluer" concept, meaning if the "glue" cannot perform his/her duties (ie got hit by bus? ) then someone else can easily step into that role and fullfill it. So that's why i have things like my "Software-O-Matic" style task listings, whereby I after specifications been written and signed off on, I then begin to itemize various tasks of what needs to be done.
Each time someone performs the task, the update the list (ie its basically a 100% complete against version x.x.x of that component).
If you're in a POC stage that relies more on visuals then server side, you can utilise the first two (Architect / UI) and do away with the bottom two for now. Then once the POC is nearly there or very close to it, come back write down specification changes / enhancement requests etc and begin an actual "development" phase of the project.
This kind of approach helped me anyway, either in a team or solo. If solo, I swap hats back and forth, and i approach an application like the above, whereby I start out building a lot of the custom visuals, then at the same time see how the fit into an overall "screen" concept. Once i have that squared away, I stop work, compare notes against spec and begin to make sure server-side adheres to the visuals or needs a further look. I then close down my flex app, and build cfmx (writing mach-ii unit testers and what not for it). Then once the CFMX side of things is running smoothly, i look at building a flexGateway.cfc or flexFacade.cfc (whatever holds your semantic-happy-zone-in-check). Which interfaces between my server-side model and my flex application making sure arguments back and forth are inline with the DTO/VO vision.
The "Gluer" can be a bludge/time wastage job at times but other times it can be very crucial as its the brains trust for the UI application.
Make sense?
On 8/25/05, Dimitrios
Gianninas <[EMAIL PROTECTED]>
wrote:
I don't think your crazy eh. Being the glue guy, never actually tried that eh, sounds like something I will have to try. I usually allow people to implement an entire use-case on their own and then just tweak the UI for them eh. That way it appears to me anyways, that we are working in parallel and delivering the final overall solution quicker. I find that with Flex, you can build the UI so fast, that if you just do UI, you then wait for the serverside to do their part before you can complete the UI work.Curiosity, how much glueing do you actually do? Or maybe your definition of glueing? I usually just review the code written every second day as the project goes along and give the boys feedback on things to tweak.Dimitrios "Jimmy" GianninasRIA DeveloperOptimal Payments Inc.
From: [email protected] [mailto:[email protected]] On Behalf Of Scott Barnes
Sent: Wednesday, August 24, 2005 11:25 PM
To: [email protected]
Subject: Re: [flexcoders] Cairngorm Development Cycle<canadian> w00t yooo tulkin aboot eh! </canadian> (no offense intended hehee)--
I've not had the luxury as yet of working with a large number of devs
in one team on an flex application, but I've had suceess in giving
portion-work to be done out. In that, I typically am the guy that
glues it all together.
In that, I can get folks to work on server-side framework (ignore UI),
simply give me a model to tap into that allows data / and objects to
be shared around as if they were currency (ie i';; give you a
profileVO, invoiceVO and you give me back a
InvoiceCostcodesCollectionVO ). I'm a firm believer in trading with
objects (like most I guess).
Then, on the UI side of things i'll ask someone to build a Panel,
which allows insert/update/delete costcodes.. meaning just give me the
visuals and an api to call in terms of populating this 'view" with
relevant data (combination of component development / viewhelper
mindset).
Then, I'll be the guy or one of them, that will piece the items
together, making sure things fit nice and snug if not, request some
refactoring or enhancements (if they follow the specs/UML/Sequence
Diagrams etc.. shouldn't be a problem).
That being said, If i am a lone coder, I also play each role like the
above, that way can break up un intended coupling and make my work
load more agile.
Cairngorm is a team framework and so if you start top-down or down-up,
its got enough hooks in place to give you a nice footing on either
direction? or am i full of crap ? (could be the later, its quite
possible hehe).
On 8/25/05, Dimitrios Gianninas <[EMAIL PROTECTED]> wrote:
>
> I've discovered the same thing here, with Flex, we typical prototype the UI
> and show it to stakeholders and thus get approval on the design and get
> immediate feedback on what we might be missing based on what we've provided
> at that time.
>
> However, come development time, I do think that giving each developer his
> own use-case to implement end-to-end (DB, serverside, UI) results in quicker
> delivery of the product. It also reduces dead-time, meantime Ui developer
> waiting for the serverside guy to complete his part before he can finish
> wiring things up at the UI level and so on.
>
> My 2 cents Canadian.
>
> Dimitrios "Jimmy" Gianninas
> RIA Developer
> Optimal Payments Inc.
>
>
> ________________________________
> From: [email protected] [mailto: [email protected]] On
> Behalf Of Scott Barnes
> Sent: Wednesday, August 24, 2005 10:03 AM
> To: [email protected]
> Subject: Re: [flexcoders] Cairngorm Development Cycle
>
>
> I've typically gone down the path of building the DB --> Serverside
> --> UI, but..
>
> I've found with FLEX, it being a new medium and in many ways its
> easier to simply build UI upfront, get the "stakeholders" chomping at
> the bit in terms of what's written in spec form vs whats being built.
>
> It also helps to visualise how this is all going to pan out. I had a
> 52+ page spec for an application I was working on, and It was pretty
> darn thorough (even sequence diagrams heh).
>
> Yet, when the time came to put it to "digital" form, we discovered a
> few specific items that were either overlooked or needed more
> attention (mainly for how the business would cope vs technically).
>
> So, to summarise, I build outward-in, Cairngorms pretty good in that
> regard as you can come back and plug in the appropriate code via the
> Business Delegate(s)
>
> (ie i've built apps without even knowing how the server-side will
> work, aswell as how the db will work). VO's were fun when doing that,
> as it sometimes pays to have "knowledge" of both so you can mirror in
> equal aspects via both technologies..
>
>
>
> On 8/24/05, Steven Webster <[EMAIL PROTECTED]> wrote:
> > Hi there,
> >
> > I posted something a month or so back with a subject "Cairngorm for
> Dummies"
> > which indicated typical workflow. Your call whether you build
> horizontally
> > (ie in layers) - for me, I typically would build an application on a
> > use-case by use-case basis, from the view to the database (usually from
> the
> > bottom up).
> >
> > But your mileage may vary...
> >
> > Steven
> >
> >
> > --
> > Steven Webster
> > Technical Director
> > iteration::two
> > [EMAIL PROTECTED]
> >
> > Office: +44 (0)131 338 6108
> > Mobile: +44 (0)7977 216 223
> >
> > This e-mail and any associated attachments transmitted with it may contain
> > confidential information and must not be copied, or disclosed, or used by
> > anyone other than the intended recipient(s). If you are not the intended
> > recipient(s) please destroy this e-mail, and any copies of it,
> immediately.
> >
> > Please also note that while software systems have been used to try to
> ensure
> > that this e-mail has been swept for viruses, iteration::two do not accept
> > responsibility for any damage or loss caused in respect of any viruses
> > transmitted by the e-mail. Please ensure your own checks are carried out
> > before any attachments are opened.
> >
> > -----Original Message-----
> > From: [email protected] [mailto: [email protected]] On
> > Behalf Of spbarber101
> > Sent: 24 August 2005 14:38
> > To: [email protected]
> > Subject: [flexcoders] Cairngorm Development Cycle
> >
> > I have just started to build an application in Flex and decided to go with
> > the Cairngorm framework. I am going to be using Coldfusion via Flash
> > Remoting as my backend business logic. Is there any particular order in
> > which developers build there applications in Flex using Cairngorm?
> >
> > What i mean, is it good to start off with the Views for example?
> >
> >
> >
> >
> >
> >
> > --
> > Flexcoders Mailing List
> > FAQ:
> http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> > Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > Flexcoders Mailing List
> > FAQ:
> http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> > Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Regards,
> Scott Barnes
> http://www.mossyblog.com
>
>
> --
> Flexcoders Mailing List
> FAQ:
> http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
>
>
>
> ________________________________
> YAHOO! GROUPS LINKS
>
>
> Visit your group "flexcoders" on the web.
>
> To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>
--
Regards,
Scott Barnes
http://www.mossyblog.com
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
Computer software testing Macromedia flex Development Software developer
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--
Regards,
Scott Barnes
http://www.mossyblog.com
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

