persisting values between two parts?

Topics: Writing modules
Feb 14, 2011 at 10:11 PM
Edited Feb 14, 2011 at 10:13 PM

Is it possible to persist values between two parts? ie.

if I create a Record and its part like Product.

Name and Description are properties in product.

In my migration class, I am adding a bodypart and routablepart. Can I persist the Title property to the Product's Name Property, as well as, persist the Bodies html property to the Product's Description property?

I apologize if this has already been asked.  I haven't found an answer to this yet and Thank you in advance.

 

Basically, I want to keep the data in the table for product, but use the fields of the body and routable parts to post the data to the db.

Coordinator
Feb 14, 2011 at 11:02 PM

Why do you want to do that?

Feb 14, 2011 at 11:41 PM

Well I am trying to do is keep the data within my module, so too speak.  I am building a Martial Art School Module.  I want to create a content type called Martial Art, it's properties are Name(string), Description(extended string), Active(bool). I also will have a content type called Program, it's properties are Name, Description, MinimumAge, MaximumAge, and Active. I want the Name property to be the same as what is in the Title field for RoutablePart and I would like the Description properties to be the same as what is in the BodyPart.

In the event, I need to take out the Martial Art pieces within the database. I have the ability too.

Coordinator
Feb 14, 2011 at 11:49 PM

The idea of parts is that each part has a single responsibility. The responsibility of the routable part is to handle the title and url. The responsibility of your part should be to handle the data that is specific to it. If you really want to, you can have a property on your part that does something like public string Name {get{return ContentItem.As<RoutablePart>().Title;}} (plus some checks in case that part actually is null of course) but I'd leave the storage to the routable part. Still, it feels unclean and I'm not sure what's wrong with just letting the routable part do its job and specialize yours to do whatever value it's actually adding rather than repeat yourself.

Feb 15, 2011 at 12:05 AM
Edited Feb 15, 2011 at 12:05 AM

I understand and i see your reasoning.  I would rather keep it clean and simple.

I appreciate your help.

Developer
Feb 15, 2011 at 9:10 PM

You could also load the desription in content handler - using eg. OnLoaded event. From what you've said I assume you have 2 content parts named MartialArtPart and ProgramPart, and a content types named Program and MartialArt, which both have a MartialArtPart on them, and Program has additionally a RoutePart and a ProgramPart. You could do something like this inside your content handler for:

OnLoaded<ProgramPart>((ctx, part) => { if(part.Is<RoutePart>()) part.Title = part.As<RoutePart>().Title });

and, accordingly, something similar for the BodyPart and Description property.

As Bertrand said, it's not perfectly clear, as you're unnecessarily doubling the data. If you want to do that because you need to display eg. a RoutePart Title in your Program .cshtml shape you don't have to copy data around. Just inside your .cshtml part shape do something like this: @Model.ContentPart.As<RoutePart>().Title (assuming you passed your part to the shape as ContentPart: named property from inside the driver Display method). This would be much cleaner.

Cheers, Piotr

Feb 18, 2011 at 6:35 PM

I honestly appreciate your help, both of you! 

Both scenario's will not work, if I want to keep the title for RoutePart and Name for MartialArt.  

Why I state this is because in My Program driver's GET Edit method. I need to return a List<MartialArtRecord> from my service.  Since Martial Art Record does not have a property for title. I had thought of changing the list to return List<MartialArtPart> but of course that is a lot of looping thru data. I would have to get the List<MartialArtRecord>, then lookup routes with ContentItemRecord_Id where = to MartialArtRecord_Id.  Then cast that list to List<MartialArtPart>.  I know its simple with Linq to query and join the tables to get my information back but it seems I am jumping thru hoops to get to the data.

Now please bear in mind that I am really liking Orchard Project and I believe this will be a great product.  All I am trying to accomplish is to get a better understanding and learn the nuances of Orchard.

Again and as always, I appreciate your help.  Thank you!

Coordinator
Feb 18, 2011 at 9:09 PM

Why would you build a list of parts (or part records)? Why not a list of items?

Feb 18, 2011 at 10:16 PM

I am not sure what you mean. Because both program and martial art are content items. They both are visible under the new link on the admin page.

Jake Kapp

On Feb 18, 2011 4:09 PM, "bertrandleroy" <notifications@codeplex.com> wrote:
> From: bertrandleroy
>
> Why would you build a list of parts (or part records)? Why not a list of items?
>
>
Coordinator
Feb 18, 2011 at 10:18 PM

You said "I need to return a List<MartialArtRecord> from my service". Why not a List<ContentItem>?

Feb 18, 2011 at 10:40 PM

I am assuming that comes ContentManager?

On Feb 18, 2011 5:18 PM, "bertrandleroy" <notifications@codeplex.com> wrote:
> From: bertrandleroy
>
> You said "I need to return a List<MartialArtRecord> from my service". Why not a List<ContentItem>?
>
>
Coordinator
Feb 18, 2011 at 10:51 PM

Yes. Did you read this by the way? http://orchardproject.net/docs/Creating-1-n-and-n-n-relations.ashx#Building_a_relation_between_content_items_35

Feb 18, 2011 at 11:53 PM

Thank you Betrand!

k, I had read it before but didn't understand it until now.  

It looks to me that it's pulling a list of Customers for the Sponsor, which Customer is a content item, which has a CustomerRecord and CustomerPart.  I am assuming.  So in this instance Sponsor is basically a Customer. I am assuming 

So in my instance, I would need to keep MartialArtRecord & MartialArtPart, driver, handler, etc (So i can persist the data to the db, as well as, be able to edit, create, & display on the admin ui).

Also I would need to keep ProgramRecord & ProgramPart, driver, handler, etc to persist data to the db and edit, create and display on the admin ui.  

Now I will need to create another Sponsor like Record & Part, driver, handler etc to persist data into the db, as well as, edit and display on the admin ui. Is this a correct assumption?

Coordinator
Feb 18, 2011 at 11:55 PM

That sounds about right.

Feb 19, 2011 at 12:00 AM

Thank you for being patient with me and I appreciate your help.

Feb 19, 2011 at 2:27 AM

hehe..... Light bulb went off!

So now I am starting to understand Orchard.

So this new Part is self sufficient. It updates, creates, etc itself. There isn't a need to code this thru any other part. 

Wow... I am starting to understand this more and more now. Thank you again! 

Developer
Feb 19, 2011 at 3:40 PM

Exactly, the Content Part should be thought as a self-sufficient, independently updatable and creatable object. And, basically, Content Item is just a collection of different Parts, which get rendered together:)