I like this idea. I can see how some might see it as a misuse of the
ORM, but it seems like a very practical approach to me, and keeps
things consistent (i.e., all Business Objects are Transfer Objects).
Thanks for sharing,
Bob
On Wed, Nov 19, 2008 at 11:05 AM, John K. <[EMAIL PROTECTED]> wrote:
>
> I didn't mean to make anyone go out and code this up for me to see if
> it worked, I was really just curious how others handled this problem.
> Thanks for trying it out though Chris!
>
> I did try it out last night myself and it worked just fine. The only
> trick was to dummy up a primary key, as Chris has done as well. In
> this case I just used the name of the person submitting the contact
> form.
>
> Most objects in a site/application are probably persisted in some way
> but there are a few that never need to be. At work we have two
> different methods we use for persisted and non-persisted data, but it
> seems kind of messy to me since 95% of the logic is the same. The
> only difference in this case is that instead of calling .save() I am
> sending an email and then throwing the data away.
>
> The only thing that get's a little messy, in my implementation, is the
> fact that I have my application set up with MG and CS and so I have
> the view, controllers, services, and then gateways/dao's. Instead of
> exposing Transfer to the service level and using it to replace all my
> gateway/dao functionality, I expose Transfer at the gateway/dao level
> as more of a wrapper. Change the ORM, change the gateways/daos
> instead of the entire service layer. You might be able to imagine how
> this kind of creates some goofiness as I have to have a method in the
> gateway that creates the empty Transfer object for me. It works, but
> I'm not entirely happy with it at the moment.
>
> If anyone else has any comments on how they accomplish this I'd love
> to hear them. And Mark, thank's for checking in to see if this worked
> and for saving me plenty of time that otherwise would have been wasted
> persisting data!
>
> John
>
>
> On Nov 19, 4:55 am, "Chris Peterson" <[EMAIL PROTECTED]> wrote:
>> Sure enough, I setup a simple transfer xml for a non-existing object:
>>
>> <object name="phantom" table="notReal">
>> <id name="ID" type="numeric" />
>> <property name="name" type="string" column="name" />
>> </object>
>>
>> Then I used it, as such:
>>
>> application.cs.getBean("transfer").new("phantom")
>>
>> and it dumped out exactly what I would expect, a transfer object of type
>> phantom, and I could use setName("foo") without any problems. Sounds like
>> an interesting method of using transfer for transient-persistance, kinda
>> cool. Maybe you could even write a save() method on there, to commit it to
>> another data location other than the database? Might be a cool way of
>> wrapping up all different data locations in a standardized way. Cool stuff,
>> good idea =)
>>
>> Chris Peterson
>>
>>
>>
>> On Wed, Nov 19, 2008 at 3:42 AM, Mark Mandel <[EMAIL PROTECTED]> wrote:
>>
>> > What happens if you create the objects with a table/columns that don't
>> > exist?
>>
>> > As long as you don't save() or get(), you shouldn't get errors.
>>
>> > Mark
>>
>> > On Wed, Nov 19, 2008 at 6:48 PM, Jared Rypka-Hauer
>> > <[EMAIL PROTECTED]> wrote:
>>
>> > > No, this isn't something that Transfer does... it has to have the
>> > > database there to provide properties for the objects, so without a DB
>> > > table you have nothing to provide the object definition. I think it
>> > > would be sweet if Transfer's config would provide a way to configure
>> > > it with objects outside the DB model that you could simply retrieve
>> > > from the Transfer object... making it into an object factory as well
>> > > as a persistence engine.
>>
>> > > You might try creating an object tagset that doesn't have a DB table
>> > > and then calling new() against it, but I think that would fail when
>> > > Transfer tried to create the metadata for the object.
>>
>> > > Something to think about, anyway.
>>
>> > > J
>>
>> > > On Nov 18, 2008, at 10:15 PM, John K. wrote:
>>
>> > >> So I've encountered this problem a few times and each time I seem to
>> > >> stumble on figuring out how to best solve it. Sorry if this has been
>> > >> discussed here, I looked through pages and pages and did some searches
>> > >> but came up with nothing.
>>
>> > >> The site I am designing has several objects (dogs, calendar events,
>> > >> ads, etc.). These all need to be created in the database, updated,
>> > >> etc. Perfect opportunity to use Transfer to make these database
>> > >> functions simple. I am able to set this up just fine and have
>> > >> incorporated validation into the works so that the data the user
>> > >> submits can be validated server side and returned to the form for
>> > >> corrections if necessary.
>>
>> > >> My problem comes in when I start to work with things like a contact
>> > >> form. I really want all the functionality of a Transfer object,
>> > >> except I'll never have to interact with the database. I will just
>> > >> validate, return the user to the form to correct errors (invalid email
>> > >> address, missing info, etc.) if necessary and then once the submission
>> > >> is valid I'll send an email to the proper administrator.
>>
>> > >> Has anyone used Transfer in this way? How so? Is it just as simple
>> > >> as mocking up and using the object but never saving the data? Have
>> > >> you come up with a better way to make this work? Maybe it's just late
>> > >> and this is as simple as it sounds.
>>
>> > >> John
>>
>> > --
>> > E: [EMAIL PROTECTED]
>> > W:www.compoundtheory.com
>>
>> --
>> Hey! I dont tell you how to tell me what to do, so dont tell me how to do
>> what you tell me to do! ~ Bender (Futurama)
> >
>
--
Bob Silverberg
www.silverwareconsulting.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
