Thanks for the replies. The reason I was thinking of transfer performing the basic validation is this is something you do on every property. I wasn't thinking of transfer doing anything like business rules. Business rules might occur on none, one or many of the properties. It would just be nice to just add it to transfer.xml and bam! you have basic validation.
In any case I'm going to look at Bob's stuff, it looks interesting. Jim On Mar 19, 5:04 pm, Brian Kotek <[email protected]> wrote: > Remember that Transfer is an ORM. It isn't meant to replace the fact that > you still have to create and maintain business objects. If you add a > property to the object, then one assumes you're going to DO something with > it, yes? Which means you have to change the object anyway. Adding a property > to the Transfer XML or updating the validation (whether it exists in the > object or in an external validation framework) takes just a few minutes and > should really be the least of your worries. More important should be how the > property affects the behavior of the object in terms of its business logic. > > You don't *need* to add a cfproperty tag to the business object itself. > That's something that Illudium does by default but it isn't required. As you > mentioned, you can change the generation template to omit this if you wish. > And you only need to add it to the creation method if you're passing the > arguments by name in a hardcoded manner. There are many ways to avoid this, > including passing a structure, passing an argumentCollection, or using the > Transfer metadata to locate the corresponding data fields and populate the > decorator with them. > > I think adding validation properties to the Transfer XML is a pretty short > road. Sure, it might help with basic validation (is this a number? is this a > date? etc.) but really, writing generic validation to handle that based on > the type defined in the Transfer metadata is pretty straightforward. That's > not the issue. The issue is when you get into non-trivial validation rules. > Which have to be written by hand anyway (unless you dive into DSL > territory). > > Bob's done some nice things with his validation framework, and I've been > doing something similar in a homegrown validation system for years. But even > if you externalize the validation rules, you still have to update something, > you've just changed what you have to update. > > > > On Thu, Mar 19, 2009 at 4:25 PM, Jim <[email protected]> wrote: > > > Yes, of course validation has to know about the properties and the > > rules. But now if a database column is added, you have to add the > > property, you have to add the validate and you have to add it into the > > arguments of the create method of the service object and you have to > > add it to the transfer.xml. So you're almost back to where you > > started if you just hand coded all of them whenever a change is > > needed. > > > I'll probaby end up changing what illudium generates to I don't have > > to make all those changes when the database is modified. I just have > > to figure out something that works for me. > > > Ideally I'd like to see attributes added to the property tag in > > transfer.xml to add validation, like length, more granular types such > > as integer, and also range. Then transfer could create the validation > > method. Maybe this is in the road map, maybe not. > > > Anyhow, just a thought. > > > Jim- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
