Cairngorm - Architectural kinda question

[Justin McCormack]

Hi all, hope this is the right list to post this type of question..
I'm sure someone can help me out.

I'm new to Flex and coming from a web/ajax background I'm struggling a
bit with the 'statefulness' of flex, compared to the relatively
'statelessness' of your typical web page.

Basically, I'm looking at building a flex app as a learning
experience. The flex app will be based on an existing web app at work.

Put simply, the application is used to allow people to submit wines
into a competition. A submission consists of several wine entries.
Each entry contains details about the wine composition, producer &
production details, retail details & stockists..

With the main application view, I want to show the user (the
submitter) the wines they have submitted in a datagrid. The datagrid
will have colums such as the wine name, vintage, producer, entry
status (paid, unpaid) and entry date.

When the user selects an entry from the winelist datagrid, I want to
show the selected entry details in an accordion view (with headings
such as entry status, wine composition, producer details, etc). Each
panel in the accordion will contain the various form fields to allow
the user to modify the entry.

Quite straightforward, right? I want to use value objects - but I have
some questions about how they should be used:

1) Can or should a VO contain references to or collections of other
VOs? For example, a wine has a producer. I have a wineVO and a
producerVO. Should I do something like wineVO.producerVO.name =
"Producer Name".

2) Should I transfer the entire submission (a submission is made up of
several wine entries aka WineVOs) to Flex in one big VO, then let the
user manipulate the submission VO (by adding, modifying entries) and
then save it back to the server? Is that good practice?

3) A wine is produced in a specific country. On the wine details form
(when editing an existing entry), I want a combo box of countries,
with the production country selected. So.. I have a VO called
'countries' in my model which contains a collection of CountryVOs (id,
name) that the combo box is bound to. Should my WineVO contain a
CountryVO or just the ID of the production country? What's the best
way to get the combo box to bind to the selected country in the WineVO
but having the dataprovider pointing to model.CountriesVO?

Sorry for the long post - I've reviewed a lot of the Cairngorm
examples, but they tend to deal with simple problems (like adding a
contact) and I'm finding it hard to build something a little more
complicated on top of their foundations.

Any advice appreciated.

Justin

[Jon Bradley-2]

On Aug 31, 2007, at 6:31 AM, Jus wrote:

> Quite straightforward, right? I want to use value objects - but I have
> some questions about how they should be used:
>
> 1) Can or should a VO contain references to or collections of other
> VOs? For example, a wine has a producer. I have a wineVO and a
> producerVO. Should I do something like wineVO.producerVO.name =
> "Producer Name".

Take all of this with a grain of salt – others may comment on what  
they believe are best practices.

I don't think there's a problem with what you are describing. A value  
object can most definitely contain value objects of it's own. There's  
no best practice here in my opinion. It's whatever works for you and  
how granular you want to make your data.

That said, if your producer just a name can you just stuff it into a  
property of the WineVO.

Still, it seems as though your application consists of just two value  
objects (to make it easy for you to do and easy to manage - for now),  
a WineVO and SubmissionVO. You could take the top down approach,  
CountryVO -> ProducerVO -> WineVO, but that's not the focus of your  
application. The focus is on the product, the important data is the  
wine itself.

> 2) Should I transfer the entire submission (a submission is made up of
> several wine entries aka WineVOs) to Flex in one big VO, then let the
> user manipulate the submission VO (by adding, modifying entries) and
> then save it back to the server? Is that good practice?

If the submission is literally just an Array or ArrayCollection of  
value objects, then you probably don't need a separate VO for it.

If it contains additional information, then it might be a good idea  
to extend a SubmissionVO as an ArrayCollection with those additional  
properties you need. Helpful if it needs to be bound to some  
dataProvider in your application.

> Should my WineVO contain a CountryVO or just the ID of the  
> production country? What's the best way to get the combo box to  
> bind to the selected country in the WineVO but having the  
> dataprovider pointing to model.CountriesVO?

At the very minimum your WineVO should have a comparable property of  
the country - either by name or by id, whatever you decide to choose.

You bind to the list of countries and at creationComplete for your  
view just set the selected item of the combo box to the name of the  
country in the WineVO. You could have a utility method that gets the  
country name based on id, but it's probably just easier to match name  
to name between the CountryVO.name and WineVO.country.

Your "submission edit" view would contain a local copy of the  
selected WineVO and you modify a temporary instance of a WineVO right  
then and there. I prefer to do any type of temporary modification to  
value objects within the view. If it's complex, the view itself may  
have it's own model, etc. Like a form, the data is all temporary  
until you commit it. The data may come in as pre-configured, but  
there's usually no use case to save each change. You can just kill  
the view without any necessary cleanup.

Say you've got your submission edit dialog....

[Bindable]
private var model : WineAppModelLocator =  
WineAppModelLocator.getInstance();

private var wine : WineVO;

// creationComplete...
private function init():void
{
        wine = model.selectedWine;
        // set combo box selected item to wine.country
        // do whatever else
}



> Sorry for the long post - I've reviewed a lot of the Cairngorm
> examples, but they tend to deal with simple problems (like adding a
> contact) and I'm finding it hard to build something a little more
> complicated on top of their foundations.

I actually think your example is equal from a complexity standpoint.  
There don't seem to be many user gestures here - maybe 3 or 4 I'm  
guessing from the start? The hardest part is how you want to  
structure your data.

good luck with it. hope something here was helpful for you.

best,

jon