Adding empty part to type fails

Topics: Troubleshooting, Writing modules
Nov 25, 2011 at 9:31 PM

AFAIK if a part (in this specific scenario, an empty part, without a record and even without properties) is attached to a type, it'll be listed in ContentItem.Parts as its own type. E. g. if a part (ContentPart child class) is attached in the migrations with its name, say, "MyPart", ContentItem.Parts[5] will contain an object of type MyPart. Now I tried to add a new part to a type, it gets added but it's stored as ContentPart in the Parts list. This is the same as when a part is not created from a class, but in migrations (like welding fields together).

However there is another part that works, used the same way. This works:

                cfg => cfg
    public class MyWorkingPart : ContentPart

But this doesn't:

                cfg => cfg
    public class MyNotWorkingPart : ContentPart
Can you see a difference?

Even if I try to attach the two parts to the same type (new type, even the installation is a wipe-out, so there should be really no difference), the same works and the same doesn't. Heck even if I copy-paste the working part, modify one letter in its name and try to attach both to the same type it shows the same failure. What kind of sorcery is this?

Any help would be really appreciated (not how to solve this, as I guess from this there can't a solution be deciphered but for a direction where I can start to investigate the problem) as I can't think of anything to solve this.

Nov 25, 2011 at 10:04 PM

Believe it or not, the problem was that the non-working part hadn't got a driver. An empty driver solved this.

Nov 25, 2011 at 11:21 PM

Yes, all parts need a driver, otherwise nothing works ;)

Jan 21, 2012 at 5:55 PM

Just on a side note, this only applies if parts are added with migrations. If they're welded dynamically (e.g. with an ActivatingFilter from a handler) no driver is required.

Aug 24, 2013 at 5:35 AM
It would be great if a future version would contain some base implementations of all of this, that you can override like in MVC itself. Not only would it decrease learning curve significantly, it would also reduce amount of work over and over. I'm talking here about correlations such as record and recordpart, part and driver and such...
Aug 25, 2013 at 12:56 AM
Interesting, And how would that look like?
Aug 25, 2013 at 12:07 PM
Edited Aug 25, 2013 at 1:15 PM
Well, I was thinking along the lines of having some of the classes being generated off of the implementation of another. For instance, a specific implementation of ContentPartWithRecord could easily be the base of an auto-generating proxy that creates/manages the corresponding ContentPartRecord with all its virtual fields. Underlying, this wouldn't change a thing for Orchard, but either a Visual Studio plugin and/or the current mechanism that reads the source files could (re)generate these proxy classes. This way you would have some easier/faster/more concise ways of developing things in Orchard, while still giving you the opportunity of implementing ContentPart<TRecord> and ContentPartRecord directly should the auto-generating stuff not be sufficient for a specific implementation.

Don't get me wrong, the way Orchard is built lends to amazing flexibility for more experienced developers, but for the majority of less experienced web developers, all of these very specific implementations make for a very steep learning curve. I truly believe that some effort in Visual Studio plugins and/or the compilation mechanism in Orchard would provide for an easier track of development and manageability of code, while keeping the core functionalities intact.

I know Orchard uses NHibernate as it's ORM, but I personally just love the way Entity Framework Code First works. By simply creating a class and using some attribute declarations, you are (re)building a database structure. The same could be true for ContentPartWithRecord, where not only ContentPart<TRecord> and ContentPartRecord can be auto-generated, but also the Migrations for it. This, to my belief, offers a great deal of transparency and code simplicity, while not taking away any of the standard way of work in Orchard.
Aug 25, 2013 at 10:59 PM
Edited Aug 25, 2013 at 11:00 PM
Well, believe it or not, but this could actually be mostly a step backwards, if not done carefully. If you dig out old versions of Orchard, you'll see that we did have what you describe, including auto-migrations. We explicitly walked away from this and made migrations "manual". If anything like this is done, it needs to be another, simpler way of doing things, not a replacement, and there must be a migration path from the simpler model to the complete one.
I'm not poo-poo-ing the idea, I suffer like anybody from having to write lots of boilerplate code. I'm just asking that things are done carefully and with due consideration for past mistakes and successes.
Aug 26, 2013 at 3:33 AM
Ok, I respect that, we shouldn't repeat past mistakes. I am definitely also not talking about a replacement, I think the current model should stay as is. I just have a dream to be able to just write a class like in EF Code First, write some attributes for it that define record fields, indexes and all that sugar, and that the boilerplate code is generated by means of a visual studio plugin or what not. This class could maybe also contain some specific methods that are overridable with code that is immediately used inside the boilerplate files...
Aug 26, 2013 at 6:55 AM
Edited Aug 26, 2013 at 6:56 AM
Well, I'm not saying that nothing should be done to try and makes things easier. But also consider that separating the record and the part is done for a reason. On the other hand, ContentPart<TheRecordType> does tie them together, and for many part records, it would make sense to just let the record be entirely generated from metadata. Then again, if we move soon to document databases, all this may need to be revised anyway.
Aug 26, 2013 at 6:59 AM
Ah ok. Well if the structure is to be revised, then it doesn't make sense to think about reworking/adding stuff to it now.
Is anything already known about the how and when of document databases?
Aug 26, 2013 at 7:06 AM
We don't know when that's going to happen, so this is probably still worth it. Don't want to discourage you really.
Aug 26, 2013 at 7:22 AM
Ok, somewhere this week I'm going to get acquainted with the new Git repo. Once I've got my head around that, I'll look into what can be done in regards to this. Any additional suggestions are always welcome of course :)