Re: [flexcoders] Cairngorm / MVC Best Practice

2007-01-12 Thread Tom Chiverton
On Friday 05 January 2007 16:07, Stembert Olivier (BIL) wrote:
 the view and the command are better decoupled with the ViewHelper
 pattern, no?

ViewHelper isn't recommended anymore, is it ?

-- 
Tom Chiverton
Helping to competently compete 24/7 mindshares



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


RE: [flexcoders] Cairngorm / MVC Best Practice

2007-01-12 Thread Dimitrios Gianninas

Actually they are more coupled that way. The ViewHelper is no longer 
recommended, it is recommended for the command to update your model and then 
your model to binded to your view so that it updated itself accordingly.

Dimitrios Gianninas
RIA Developer
Optimal Payments Inc.

-Original Message-
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
Chiverton
Sent: Friday, January 12, 2007 4:16 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Cairngorm / MVC Best Practice

On Friday 05 January 2007 16:07, Stembert Olivier (BIL) wrote:
 the view and the command are better decoupled with the ViewHelper 
 pattern, no?

ViewHelper isn't recommended anymore, is it ?

--
Tom Chiverton
Helping to competently compete 24/7 mindshares



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.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




-- 
WARNING
---
This electronic message and its attachments may contain confidential, 
proprietary or legally privileged information, which is solely for the use of 
the intended recipient.  No privilege or other rights are waived by any 
unintended transmission or unauthorized retransmission of this message.  If you 
are not the intended recipient of this message, or if you have received it in 
error, you should immediately stop reading this message and delete it and all 
attachments from your system.  The reading, distribution, copying or other use 
of this message or its attachments by unintended recipients is unauthorized and 
may be unlawful.  If you have received this e-mail in error, please notify the 
sender.

AVIS IMPORTANT
--
Ce message électronique et ses pièces jointes peuvent contenir des 
renseignements confidentiels, exclusifs ou légalement privilégiés destinés au 
seul usage du destinataire visé.  L'expéditeur original ne renonce à aucun 
privilège ou à aucun autre droit si le présent message a été transmis 
involontairement ou s'il est retransmis sans son autorisation.  Si vous n'êtes 
pas le destinataire visé du présent message ou si vous l'avez reçu par erreur, 
veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses 
pièces jointes, de votre système.  La lecture, la distribution, la copie ou 
tout autre usage du présent message ou de ses pièces jointes par des personnes 
autres que le destinataire visé ne sont pas autorisés et pourraient être 
illégaux.  Si vous avez reçu ce courrier électronique par erreur, veuillez en 
aviser l'expéditeur.



--
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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


RE: [flexcoders] Cairngorm / MVC Best Practice

2007-01-12 Thread Stembert Olivier (BIL)
I don't know. Why is it still in the framework? 

-Original Message-
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Chiverton
Sent: Friday, January 12, 2007 10:16 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Cairngorm / MVC Best Practice

On Friday 05 January 2007 16:07, Stembert Olivier (BIL) wrote:
 the view and the command are better decoupled with the ViewHelper 
 pattern, no?

ViewHelper isn't recommended anymore, is it ?

--
Tom Chiverton
Helping to competently compete 24/7 mindshares



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England
and Wales under registered number OC307980 whose registered office
address is at St James's Court Brown Street Manchester M2 2JF.  A list
of members is available for inspection at the registered office. Any
reference to a partner in relation to Halliwells LLP means a member of
Halliwells LLP. Regulated by the Law Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and
may be confidential or legally privileged.  If you are not the addressee
you must not read it and must not use any information contained in nor
copy it nor inform any person other than Halliwells LLP or the addressee
of its existence or contents.  If you have received this email in error
please delete it and notify Halliwells LLP IT Department on 0870 365
8008.

For more information about Halliwells LLP visit www.halliwells.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




-
An electronic message is not binding on its sender.
Any message referring to a binding engagement must be confirmed in
writing and duly signed.
-


-
An electronic message is not binding on its sender.
Any message referring to a binding engagement must be confirmed in writing and 
duly signed.
-



RE: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Dimitrios Gianninas
1) A delegate can contain many methods pertaining to a particuliar section of 
your app. So many command will use the same delegate.
 
2) No.
 
3) Why exactly are u looking to do?
 
4) If I eliminate it... then where is the sample :)
 
IF you have view, then it will dispatch various commands to do the associate 
work of getList, create, load, save and delete... this is pretty typical.
 
Dimitrios Gianninas
RIA Developer
Optimal Payments Inc.
 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jamie O
Sent: Thursday, January 04, 2007 5:04 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Cairngorm / MVC Best Practice



It's Thursday afternoon, which means my bi-weekly question everything
I've just coded and contemplate serious internal changes on the
project. This week the insanity relates to Cairngorm or perhaps Model
View Controller design pattern in general, and the best practices of
it's implementation.

Short Questions:
1) How do you break up your commands / delegates?
2) Is there a way - similar to how a delegate can have a series of
functionname_onResult, functionname_onFault - that you can have one
command deal with multiple onResult scenarios?
3) Are there any examples out there which deal with these situations
specifically? My googles have not lead to good details, but perhaps
I'm just querying for the wrong terminology at this point
4) If you're delegate(s) are so simplistic to just act as a gateway,
what would a sample look like where you eliminte it?

Example Context: You have a screen (view) in which a user can display
a list of tasks, select one to display, select one to edit, select one
to delete, or add a new one. You'll also have a host of other
functions with similar scope (Add staff, Add materials, etc) for
arguments sake.

Long Thoughts:
My initial thoughts built up from Jesse's Amazon Web Service example
-Create one custom event (Task) that has a sub-event type for each
activity (list, display, add, edit, delete) as a series of constants
defined in the event itself.

-The execute function in the command (also a responder) would be a
giant switch statement that passes off the different pieces of data
from the event to the appropriate function within the command.

-Each of these calls a delegate to hit a back-end service to get what
is required of it and return the results to the command to update the
model and the view responds accordingly.

This breaks down when I have more than one function returning results
from a delegate because I can only have one 'onResult' function within
the command. How to code for the differences of if it was a delete
action to return the view back to the list of task state versus an
edit action to return to the display state for that updated task.

My second intention is to create a specific command for each activity
(TaskAddCommand, TaskEditCommand, TaskDeleteCommand) and keep the
event as described above. But is doing the following in the controller
adviseable:
addCommand(TaskEvent.ADDTASK, TaskAddCommand);
addCommand(TaskEvent.EDITTASK, TaskEditCommand);
addCommand(TaskEvent.DELETETASK, TaskDeleteCommand);

This is still plagued by the delegate having a huge amount of code
just acting as passthru service, but would still be something that
coding conflicts would arise on.

If you're delegate(s) are so simplistic of just acting as a gateway,
what would a sample look like where you eliminte it? Then I could
stick with one event type with sub-types, each sub-type references a
specific command which does it's own service call / response.

Thx,
Jamie



 

-- 
WARNING
---
This electronic message and its attachments may contain confidential, 
proprietary or legally privileged information, which is solely for the use of 
the intended recipient.  No privilege or other rights are waived by any 
unintended transmission or unauthorized retransmission of this message.  If you 
are not the intended recipient of this message, or if you have received it in 
error, you should immediately stop reading this message and delete it and all 
attachments from your system.  The reading, distribution, copying or other use 
of this message or its attachments by unintended recipients is unauthorized and 
may be unlawful.  If you have received this e-mail in error, please notify the 
sender.

AVIS IMPORTANT
--
Ce message électronique et ses pièces jointes peuvent contenir des 
renseignements confidentiels, exclusifs ou légalement privilégiés destinés au 
seul usage du destinataire visé.  L'expéditeur original ne renonce à aucun 
privilège ou à aucun autre droit si le présent message a été transmis 
involontairement ou s'il est retransmis sans son autorisation.  Si vous n'êtes 
pas le destinataire visé du présent message ou si vous l'avez reçu par erreur, 
veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses 
pièces jointes, de votre système.  La lecture, la distribution, la

Re: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Tom Chiverton
On Thursday 04 January 2007 22:03, Jamie O wrote:
 2) Is there a way - similar to how a delegate can have a series of
 functionname_onResult, functionname_onFault - that you can have one
 command deal with multiple onResult scenarios?

We have all our Events take the current object as the first parameter 
(i.e. 'this').
The Command then calls 
savedFromEventHome.onCommandName(result)
in onResult.

Could that do what you want ?

-- 
Tom Chiverton
Helping to advantageously fashion web-enabled clusters



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


Re: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Martin Wood-Mitrovski
 We have all our Events take the current object as the first parameter 
 (i.e. 'this').
 The Command then calls 
 savedFromEventHome.onCommandName(result)
 in onResult.
 
 Could that do what you want ?

interesting.

do these objects then implement some kind of interface to support the 
'onCommandName(result)' method or do you type it in some other way? (casting in 
the command, strict all the way through etc..)


martin.



--
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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


Re: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Tom Chiverton
On Friday 05 January 2007 14:51, Martin Wood-Mitrovski wrote:
 do these objects then implement some kind of interface to support the
 'onCommandName(result)' method or do you type it in some other way?

No, you could (should ?) write an interface class and import it though, yes.
As long as we remember to make the function public rather than private it 
works really well. We like it much better than the old ViewHelper way of 
doing things as now your result handler code is right there with the 
invocation code.

-- 
Tom Chiverton
Helping to competently harness back-end content



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England and 
Wales under registered number OC307980 whose registered office address is at St 
James's Court Brown Street Manchester M2 2JF.  A list of members is available 
for inspection at the registered office. Any reference to a partner in relation 
to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law 
Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and may be 
confidential or legally privileged.  If you are not the addressee you must not 
read it and must not use any information contained in nor copy it nor inform 
any person other than Halliwells LLP or the addressee of its existence or 
contents.  If you have received this email in error please delete it and notify 
Halliwells LLP IT Department on 0870 365 8008.

For more information about Halliwells LLP visit www.halliwells.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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


RE: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Stembert Olivier (BIL)
the view and the command are better decoupled with the ViewHelper
pattern, no? 

-Original Message-
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Chiverton
Sent: Friday, January 05, 2007 4:42 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Cairngorm / MVC Best Practice

On Friday 05 January 2007 14:51, Martin Wood-Mitrovski wrote:
 do these objects then implement some kind of interface to support the 
 'onCommandName(result)' method or do you type it in some other way?

No, you could (should ?) write an interface class and import it though,
yes.
As long as we remember to make the function public rather than private
it works really well. We like it much better than the old ViewHelper way
of doing things as now your result handler code is right there with the
invocation code.

--
Tom Chiverton
Helping to competently harness back-end content



This email is sent for and on behalf of Halliwells LLP.

Halliwells LLP is a limited liability partnership registered in England
and Wales under registered number OC307980 whose registered office
address is at St James's Court Brown Street Manchester M2 2JF.  A list
of members is available for inspection at the registered office. Any
reference to a partner in relation to Halliwells LLP means a member of
Halliwells LLP. Regulated by the Law Society.

CONFIDENTIALITY

This email is intended only for the use of the addressee named above and
may be confidential or legally privileged.  If you are not the addressee
you must not read it and must not use any information contained in nor
copy it nor inform any person other than Halliwells LLP or the addressee
of its existence or contents.  If you have received this email in error
please delete it and notify Halliwells LLP IT Department on 0870 365
8008.

For more information about Halliwells LLP visit www.halliwells.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




-
An electronic message is not binding on its sender.
Any message referring to a binding engagement must be confirmed in
writing and duly signed.
-


-
An electronic message is not binding on its sender.
Any message referring to a binding engagement must be confirmed in writing and 
duly signed.
-



Re: [flexcoders] Cairngorm / MVC Best Practice

2007-01-05 Thread Martin Wood-Mitrovski
Tom Chiverton wrote:
 On Friday 05 January 2007 14:51, Martin Wood-Mitrovski wrote:
 do these objects then implement some kind of interface to support the
 'onCommandName(result)' method or do you type it in some other way?
 
 No, you could (should ?) write an interface class and import it though, yes.
 As long as we remember to make the function public rather than private it 
 works really well. We like it much better than the old ViewHelper way of 
 doing things as now your result handler code is right there with the 
 invocation code.

So you mean that the object that invokes the service and handles the result is 
typed all the way through, its only the event that you have to cast in the 
command.

I agree that having the result handler next to the invocation is preferable, im 
not sure if its really worth the trouble of creating an interface for this, 
after all it seems unlikely to need that flexibility...unless of course at some 
point you wanted to shift the result handlers into their own class or 
something.im getting dangerously close to rambling.. ;)

Anyway..i'm still getting to grips with the Cairngorm style and how best to 
bend 
it to my will, so its interesting to see other choices and implementations.

Also this way matches my AS2 setup much more closely as well which is nice. :)

Martin.


--
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

* To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

* Your email settings:
Individual Email | Traditional

* To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

* To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

* Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 


[flexcoders] Cairngorm / MVC Best Practice

2007-01-04 Thread Jamie O
It's Thursday afternoon, which means my bi-weekly question everything
I've just coded and contemplate serious internal changes on the
project. This week the insanity relates to Cairngorm or perhaps Model
View Controller design pattern in general, and the best practices of
it's implementation.

Short Questions:
1) How do you break up your commands / delegates?
2) Is there a way - similar to how a delegate can have a series of
functionname_onResult, functionname_onFault - that you can have one
command deal with multiple onResult scenarios?
3) Are there any examples out there which deal with these situations
specifically? My googles have not lead to good details, but perhaps
I'm just querying for the wrong terminology at this point
4) If you're delegate(s) are so simplistic to just act as a gateway,
what would a sample look like where you eliminte it?

Example Context: You have a screen (view) in which a user can display
a list of tasks, select one to display, select one to edit, select one
to delete, or add a new one. You'll also have a host of other
functions with similar scope (Add staff, Add materials, etc) for
arguments sake.

Long Thoughts:
My initial thoughts built up from Jesse's Amazon Web Service example
-Create one custom event (Task) that has a sub-event type for each
activity (list, display, add, edit, delete) as a series of constants
defined in the event itself.

-The execute function in the command (also a responder) would be a
giant switch statement that passes off the different pieces of data
from the event to the appropriate function within the command.

-Each of these calls a delegate to hit a back-end service to get what
is required of it and return the results to the command to update the
model and the view responds accordingly.

This breaks down when I have more than one function returning results
from a delegate because I can only have one 'onResult' function within
the command. How to code for the differences of if it was a delete
action to return the view back to the list of task state versus an
edit action to return to the display state for that updated task.

My second intention is to create a specific command for each activity
(TaskAddCommand, TaskEditCommand, TaskDeleteCommand) and keep the
event as described above. But is doing the following in the controller
adviseable:
addCommand(TaskEvent.ADDTASK, TaskAddCommand);
addCommand(TaskEvent.EDITTASK, TaskEditCommand);
addCommand(TaskEvent.DELETETASK, TaskDeleteCommand);

This is still plagued by the delegate having a huge amount of code
just acting as passthru service, but would still be something that
coding conflicts would arise on.

If you're delegate(s) are so simplistic of just acting as a gateway,
what would a sample look like where you eliminte it? Then I could
stick with one event type with sub-types, each sub-type references a
specific command which does it's own service call / response.

Thx,
Jamie