LiveDocs Comments - wtg - public - machiidevguide - models.html

wtg/public/machiidevguide/models.html

SeanCorfield — 2006-04-14T15:31:46

No, you cannot put a try block around the argument tags. If you want more control over argument validation, you need to define arguments as string type (or any type) and then perform explicit validation on the arguments yourself.

However, your model probably should be strongly typed, except for beans that are used to handle user input. The controller layer should ensure that all the necessary validation is performed on user input (via the beans).

Any invalid arguments passed to your core model should then be considered unexpected errors - exceptions - and it is appropriate for cfargument's type specification to handle that (and throw an exception that the controller can catch and decide how to notify the user about the programming logic failure that has occurred).

wtg/public/machiidevguide/models.html

SRI-CTPino — 2006-04-13T16:53:19

Can a series of cfargument tags within the init method declaration be enclosed with a cftry block or blocks?

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-11-12T07:31:34

For a mixture of required and non-required fields, you can omit the field list from the event-bean tag and let it do the initialization of your bean through the init() method.

Your init() method would have cfargument tags for all the form fields and specify required="true" or required="false" as appropriate.

wtg/public/machiidevguide/models.html

cedgar — 2004-11-12T07:09:31

Is there a best practice for handling non-required form data that map onto ColdFusion boolean, date and numeric datatypes?

I cannot see an elegant solution when trying to use the tag with a strongly typed CFC bean.

Chris

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-10-01T07:40:59

macromedia.com uses a hardware load balancer rather than JRun's built-in load balancer and uses sticky session (on the load balancer).

You can read about the macromedia.com architecture in a Developer Center article by Brandon Purcell and Frank DeRienzo.

We have not found the lack of CFC replication to be a problem (and we use CFCs in session scope very heavily). The shopping cart in the online store is a session CFC but because we have a persistent cart - stored to the database - the session CFC would be recovered if a server went down during a customer transaction.

wtg/public/machiidevguide/models.html

cedgar — 2004-10-01T03:24:18

I am keen to implement Mach II especially since we are doubling our developers in the near future. However the topic regarding CFC's not replicating in a clustered environment is causing me to rethink this direction change.

Is there a justified excuse for macromedia leaving out this feature in the current MX 6.1 release?

Do Macromedia intend on enabling this feature in the future, if so when?

Is there any workarounds, I know STICKY SESSIONS is available but that doesn't help when one or more servers go down?

Chris

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-07-07T09:13:31

Bear in mind that in CFMX 6.1, CFCs in session scope will not replicate across a cluster. Also, cflock does not operate across a cluster (locking is per server instance).

wtg/public/machiidevguide/models.html

sanaullah — 2004-07-07T05:26:39

one more thing i really like that is memento way of getting and setting of data... i have continous steps forms , in that way a simple memento variables can holds many form fields and very easy to manipulate... in some situaiton we can use bean, but honestly your first method was excellent. I would certainly like to see some more indepth detail about memento way of handling in machII.

wtg/public/machiidevguide/models.html

sanaullah — 2004-07-07T05:16:11

Using cflock is problem in Jrun clustering .... when we are using session replicationin clustering environment. The code works fine without cflock ..... even i have applied session Façade... have probelem with unique cflock

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-06-04T10:11:24

Make sure you have MACHII_CONFIG_MODE set to 0 or -1 so that
Mach II does not reload the XML configuration file on each request.
You should be seeing basic request times around 30-50ms.

wtg/public/machiidevguide/models.html

2004-06-03T17:47:27

I'm experiencing some serious performance problems using Mach II. I'm doing very minor I/O (XML) on each request that would normally take a few hundred milliseconds. Using Mach II, the average page load takes 3000 ms or more.

Perhaps I'm making MVC newbie mistakes, but they aren't quite obvious. My code is hardly any different from the samples provided on mach-ii.com. I'd be willing to share the code if anyone wants to look at it.

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-05-25T08:10:40

Since mach-ii.xml is read using the cffile tag, it would not be processed by ColdFusion even if it had a .cfm extension (so your suggestion will not work, I'm afraid).

wtg/public/machiidevguide/models.html

2004-05-24T20:14:04

If I remember it correctly, mach-ii.xml can be replace by mach-ii.xml.cfm
In this way, I think you can group your event-handlers as you like by simply using like this :

By doing this way, I can see the event-handlers are properly grouped and no modification in mach-ii core file is needed.

crab

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-04-18T12:37:18

No, we don't have a segmented configuration file. CVS merge is used to reconcile edits by multiple developers to the same file, not to take multiple files and join them together.

wtg/public/machiidevguide/models.html

2004-04-18T00:27:36

Ahh, so you DO have a segmented configutation document, but use external processes to manage it, as opposed to using mach-ii processes. Fair enough. Fair enough.

wtg/public/machiidevguide/models.html

SeanCorfield — 2004-04-13T10:56:11

The comparison between the size of a CFC file and the size of the XML file was just meant to indicate that size per se has not proved to be a problem.

According to threads on the Mach II forum, folks who've tried to break XML files into pieces and use some sort of preprocessing directive, as you describe, have found that the effort is not worthwhile and managing multiple files is actually more trouble than dealing with a single large file.
Source code control - with a built-in merge - really helps multi-developer teams work together. We use CVS and find it invaluable.

wtg/public/machiidevguide/models.html

2004-04-12T20:18:23

That justification is somewhat flawed. Very large CFC's are fine so long as they are cohesive. It is very likley that a single very large mach-ii.xml file will not be cohesive. There is no good reason not to have a cohesive xml file.

Some sort of subsidiary xml file directive would be very useful in maintaining a cohesive xml file and also would allow more than one developer to simultaneously maintain those cohesive 'islands' of configuration xml.

wtg/public/machiidevguide/models.html

SeanCorfield — 2003-12-22T19:46:00

Actually, we're not finding the single XML file to be a problem - we
have lots of CFCs that are bigger than that already.

wtg/public/machiidevguide/models.html

cducker — 2003-12-22T11:54:35

I see, so as long as you have enough memory it should be fine.

Doesn't maintaining the mach-ii.xml file become a pain when it's over 1,000 lines? Have you guys thought of a method to package related event handlers, etc into smaller mach-ii.xml files so they're more managable? The main mach-ii.xml file could contain paths to each of the smaller .xml files and when the app is loaded it could merge all the .xml docs into one mach-ii xml object and then load that into memory?

wtg/public/machiidevguide/models.html

SeanCorfield — 2003-12-19T10:40:18

We have not encountered any performance problems with large XML files.
We have high traffic applications on macromedia.com that have mach-ii.xml
files containing 1,000 lines or more.
Since the XML file is read only at startup, the size of it should not affect an
application when it is running.

wtg/public/machiidevguide/models.html

cducker — 2003-12-08T18:32:04

Have you guys encountered any proformance problems in big applications where the mach-ii.xml becomes really large due to the number of event handlers, listeners, views, etc?