Ok. Let's try this.
My app handles products which are made of scalar values (like price, name)
and of details, themselves made of other scalar values (size, weight etc)
in a one->many relationship
So
Step 1 : action showProduct
$product = $documentManager->find('Product', $id);
$this->view->product = $product;
$_SESSION['product'] = $product; // This is saving the product so I don't
have to fetch it again and to guarantee that I will use the same no matter
if the db changes from now until the end of the process
// Displays a form and the product information. The user decides if he
wants to use this product. If he decides to do so calls Step 2
Step 2 : action confirm
$this->view->product = $_SESSION['product'];
$context->save(session_id, $product); // This context serializes the
product object for future use and saves in a persistence medium (db, file,
redis, memcache). in real life this context would save other objects needed
as well
// Display a confirmation page with the details
Step 3: action postback // At some point we will get called with the
session_id saved on step 2.
$id = $_GET['id'];
$product = $context->restore($id);
$myClass->process($product);
class myClass {
public function process(Product $product) {
// inspect the product values and do something like send email,
update inventory etc
}
}
class Detail {
}
class Product {
$id;
$name;
/**
* @var Detail
*/
$details = array();
}
On Sun, May 3, 2015 at 10:20 PM, Marco Pivetta <[email protected]> wrote:
> Hi Mario,
>
> I don't have an overview of what you are doing, or better I didn't
> understand what you are doing it (and why the serialization is required).
>
> Could you make a pseudo-code example (under 30-ish LOC)? Just to
> understand the concept of what you are trying to do.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 4 May 2015 at 03:09, mbneto <[email protected]> wrote:
>
>> Hi Marco,
>>
>> Thank you for your reply.
>>
>> I understand what you are proposing but I have a hard time to try to
>> solve is the duplication of code.
>>
>> In one application that I have to maintain I have to deal, for example,
>> with a process where the user selects a list of Products, retrieved from
>> the DB, and depending on the operation he demands, I have to process right
>> away or wait for an external system to notify me of the result (via
>> postback to a different URL). The user will either see the OK your request
>> has been processed or you request is in our queue and you will be
>> notified...
>>
>> When an external system postbacks to me I have to take this list, stored
>> in the db, process it - feeding the Product entities.
>>
>> In my idea I would have the same method that takes the list of Products,
>> either they came fresh from the DB or unserialized from the initial
>> request. That is what I do using an internal db layer that pretty much
>> does the mysqli query and returns entities using a map from the column name
>> to the property name.
>>
>> But I want to remove this in favor for Doctrine ORM/ODM.
>>
>> In the approach suggested I would define and use Doctrine to retrieve the
>> products from the DB but upon saving for further processing I'd have to
>> create something to store it as the ValueObjects that can be safely
>> serialized/deserialized. And my method to process would have to accept
>> both types of lists (the Products from the DB and the Products Value
>> Objects).
>>
>> I hope there is something that can be done without having to do such.
>>
>> On Sat, Apr 4, 2015 at 10:58 PM, Marco Pivetta <[email protected]>
>> wrote:
>>
>>> Hi Mario
>>>
>>> On 5 April 2015 at 03:51, mbneto <[email protected]> wrote:
>>>
>>>> Hi Marco,
>>>>
>>>> Thank you for the reply. As part of some applications I see the
>>>> following happening:
>>>>
>>>> 1st - Request
>>>> a) fetch data from persistence layer
>>>> b) map them to Objects
>>>> c) use some in the request itself
>>>> d) save some in a session layer
>>>>
>>>> 2nd - Request (part of the same application process - perhaps the
>>>> submit of the form)
>>>> a) restore the session data
>>>> b) update the Objects based on the form data
>>>> c) persist some of the objects back - updating the content
>>>>
>>>> While not all objects would have the Doctrine annotation, some may
>>>> have, even if I use them for read only purposes.
>>>>
>>>> Right now I can do it fine because they are POPO and I map them
>>>> manually when I first do the search. After this I can
>>>> serialize/deserialize at will.
>>>>
>>>> Of course the idea is to use Doctrine to prevent me from having to do
>>>> such mapping manually - and to have all the extra features Doctrine
>>>> provides.
>>>>
>>>> In this scenario what would be me course of action?
>>>>
>>>
>>> This is what most of us ended up with, but it's actually a mess to deal
>>> with, and that with or without ORM.
>>>
>>> The best approach, in my opinion, and especially with multi-step forms,
>>> is to have form-specific DTOs/ValueObjects that you can actually safely
>>> store in session data or in a transient storage location that you can
>>> reference somehow.
>>>
>>> This greatly simplifies the entire process, and is also much safer and
>>> reliable than just making complex forms interact with your persistence
>>> layer (which, honestly, is quite problematic in first place).
>>>
>>> Greets,
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "doctrine-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/doctrine-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "doctrine-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/doctrine-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "doctrine-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/doctrine-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.
