Record persisting advices

Not a question, but advices for those who want to persist standalone record objects with the default repository. I learned these the hard way, maybe they could be part of the docs?

Store an enum as a string in the DB: the record can have an enum, but in the migration declare the corresponding column as a string. This not only gives a human-readable form of the enum value to store, but makes storage possible in the
first place: when declaring a column as an enum, the result is an exception with "Data conversion failed. [ OLE DB status value (if known) = 2 ]".

Records should have and Id field: I suppose this is enforced (?) because the repository sometimes requires one. Not having an Id field results in a "No persister for: RecordName" exception, and shouting "But it's THERE!"
doesn't help either :-).

When storing a DateTime field, either declare it nullable (with marking the type in the record property with a question mark)
or always fill it with data (from an IClock instance): not doing this results in "An overflow occurred while converting to datetime." exception

I haven't thought about writing a book :-). Actually I don't really find software development books (even if e-books) the best way to store knowledge as their topic changes quickly and often. I think it's better to have such knowledge in a more accessible way
where the audience can easily give feedback, like in the form of a demo module or a wiki-like resource.

True, although wiki's don't always give you the same easy way of searching for info like in an e-book, and an e-book also lends to easy PDF annotation and such, which makes it easier to bundle one's personal thoughts and experiences with the info in the
provided content. On top of this, wiki's need a lot of clicking around, where an annotated PDF is very easily searchable or navigateable to certain bookmarks. I'm definitely not thinking towards printed books. I don't want to critisize what you're doing in
any way, as I think it's amazing that you are putting this much effort in it, it's just my 2 cents on the topic.

I also have a question for you: how would upcoming certification work? Are you planning certifications in Europe, or even online? Or is this going to be US only? As I see Orchard CMS as a strategic part of my business and customers, I would definitely be interested
in certification, but a trip to the US to do so might not be very feasible...

Agreed on the advantages of having full documents. BTW I have thought about generating a linear pdf by flattening a tree of markdown files (connected with links, determined by the directory structure or somehow else), like from the Dojo Library. What do
you think?

But actually a book could be written in markdown as well (this would allow easy collaboration of multiple authors and even the usual goodies of open source like pull requests), though not as a single huge file (would cause issues for editors) but somehow divided...

Certifications are far from being a complete concept; we're currently evaluating different options of approaching the question. But we're based in Hungary, so if we'll have something limited to the geographical location (what definitely don't want) it won't
be the US, or not just the US :-).

Glad that you find our efforts useful, getting such feedback really makes us happy to go on with our work!

To be honest, I didn't have the slightest clue what markdown was about, I always replaced it with CKEditor. Now that I have read about it, I think it's awesome. I am wondering if the Orchard.Markdown module could be easily extended with some minor syntax
for insertion of specific stylized divs and such, but that's a whole other topic.

A flattened and searchable PDF is definitely a grand idea, as well as a Git based book. How would you go about building it into a PDF, however? I must say I really like the way the Training Demo Module is built, I'm also thinking that might be superb to be
flattened inside the book as well, with the code samples immediately inline. This would also allow for easy search and annotation.

Glad to hear that certifications might be in my reach, Orchard really deserves a level up in regards to knowledged people that implement it. No matter how magnificent a software tool is, if it is implemented by someone that has a very limited knowledge about
it, the customer adoption of the tool is very poor. Either the customer thinks the tool is crappy, because the implementor is good at (over)selling himself, or the tool simply gets a bad name because the customer sees that a good tool is implemented by a crappy
person :) (I do not wish to generalize to anyone that reads this and builds Orchard sites, just referring to my own limited knowledge and the road to learning I experienced so far).

Well, it's taken me a while to actively take part in the forums, but as I see Orchard as strategic now, I can't help but give my 2 cents to see this tool grow. I sincerely hope to be able to contribute to it.

I've been playing around a bit with Markdown, and have come to the following small sample that I want to include with each site from now on, I think it's very easy for a customer to use instead of all the HTML tags. Maybe this could be a part in the book?
It's such a small feature, but has a very large impact to usability for an end-user I think, and I've overlooked it for the past year:

Starting a new line is done by at least 2 spaces following the text
This is *italic* text
This is **bold** text
this is ***bold and italic*** text
# This is heading 1
## This is heading 2 (we can go to 6)
> This is a block quote
this is some code
- unordered item 1
- unordered item 2
1. ordered item 1
2. ordered item 2
[this is a link](http://www.google.com "search")
![this is an image](Media/OrchardLogo.png "Orchard Logo")
---------------------------------------

With the above sample it immediately shows that the Orchard editor sample doesn't display italic, images and certain line breaks correctly by the way :)

I haven't thought much about the .md-pdf generation (or rather: about Dojo Library to psd), it's just an idea I was considering before and now it came to my mind as we started to discuss this :-). But it certainly wouldn't be trivial to generate a linear pdf
from a graph (not even a tree, now it comes to me) of .md files... But I might think about this further, because the question is interesting.

FYI now we have the
Download as... module (documentation and release-ready version coming soon) that currently does HTML downloads for content items. Soon we'll have PDF support and will deploy it to Orchard Dojo.

Hi all! Not a question, but advices for those who want to persist standalone record objects with the default repository. I learned these the hard way, maybe they could be part of the docs? Store an enum as a string in the DB: the record can have
an enum, but in the migration declare the corresponding column as a string. This not only gives a human-readable form of the enum value to store, but makes storage possible in the first place: when declaring a column as an enum, the result is an exception
with "Data conversion failed. [ OLE DB status value (if known) = 2 ]". Records should have and Id field: I suppose this is enforced (?) because the repository sometimes requires one. Not having an Id field results in a "No persister for: RecordName"
exception, and shouting "But it's THERE!" doesn't help either :-). When storing a DateTime field, either declare it nullable (with marking the type in the record property with a question mark) or always fill it with data (from an IClock instance):
not doing this results in "An overflow occurred while converting to datetime." exception I hope this will help someone.

We patched in an EnumScalar attribute into the core recently.

Attach it to an enum property, and it'll store it as a scalar instead of a string ;)

We also have a DateTime2 attribute that will 'fix' the fact that it wouldn't store the DateTime' milliseconds if attached to a DateTime property.

Wish this kind of support could be included in the 'core' but I'm not sure if it is wanted there.

@2LM: Thanks, somehow the conversion failed, now it's good again. BTW I updated the module and now it experimentally supports Markdown too. It goes through HTML first which sounds silly for Dojo Library that is Markdown originally but for now this was
simple to implement.

@AimOrchard: Actually storing an enum as a string is not a must (it's just that records enums are not a valid DB type) but a good practice. This way the value will be human-readable and also it won't break if you change the order of the enum's values or insert
new values to the anywhere but not after the last one.
The DateTime attribute sounds reasonable and if it's just an attribute that wouldn't break anything. I don't know of course whether there would be enough users to actually make use of it. But you could certainly publish it in a module (maybe together with other
smaller features like I've done with
Helpful Libraries and
Helpful Extensions).

@AimOrchard: Actually storing an enum as a string is not a must (it's just that records enums are not a valid DB type) but a good practice. This way the value will be human-readable and also it won't break if you change the order of the enum's values
or insert new values to the anywhere but not after the last one.
The DateTime attribute sounds reasonable and if it's just an attribute that wouldn't break anything. I don't know of course whether there would be enough users to actually make use of it. But you could certainly publish it in a module (maybe together with other
smaller features like I've done with
Helpful Libraries and
Helpful Extensions).

Not sure if I can put it in a module, are there extension points for NHibernate to allow these convention attributes?

@AimOrchard: I'm not sure but I think in 1.7 there are new extension points for NHibernate, yes.

@2LM: that's actually hilarious, from FF I can reliably download a correct file and from Chrome it's blank. I don't know why but until I investigate I can send you the file if you send me your e-mail address :-).