How to - extending nopCommerce (1.X versions)

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
12 years ago
skyler.severns wrote:
http://csharpwebdeveloper.com/updating-exisiting-nopcommerce-2-entity

I've started to blog about extending nopCommerce. More to come, but it is a start.

-sky

Can you start a blog on how to add a new table/entity/new page. Thanx

Yes tmathura my plan was to complete the following entries as soon as possible

- Adding a new entity
- Creating a payment plug-in
- Localization


thanx you
12 years ago
From Skylers blog I see that mapping is hardcoded in the constructor. That demands the original code to be changed each time we add or change an entity.
May I suggest (maybe for version 2.1) that mappings are read from multiple xml files.
That way one could only write a simple xml file that adds a new field mapping to the mapping class; and in order to add field to the entity itself, write another part of the partial class of the entity.
12 years ago
https://www.nopcommerce.com/boards/t/5257/add-field-to-registration-form.aspx

Plz guys help me.
12 years ago
bojan.hrnkas wrote:
From Skylers blog I see that mapping is hardcoded in the constructor. That demands the original code to be changed each time we add or change an entity.
May I suggest (maybe for version 2.1) that mappings are read from multiple xml files.
That way one could only write a simple xml file that adds a new field mapping to the mapping class; and in order to add field to the entity itself, write another part of the partial class of the entity.


Thanks for the response! Here are a couple things to think about when it comes to external xml files.

1. You have to read them, parse them, and they will not be verified during compilation. This will add delays and opacity to the project

2. You will need to store them, and distribute them, by marking them as embedded resources they will come with the project, but it still requires a recompile so there is no such thing as a "hot-swap" mapping file.

3. I read code first supports DRY (Don't repeat yourself). Through inheritance child entities would only need the new features mapped. I'll need to find the article again.

But given  the scenario you provided, what kind of value would changing to XML add?
12 years ago
skyler.severns wrote:


3. I read code first supports DRY (Don't repeat yourself). Through inheritance child entities would only need the new features mapped. I'll need to find the article again.

But given  the scenario you provided, what kind of value would changing to XML add?


Alright, if you can map new features in an extra file, that renders my post invalid.
My concern was about having to change the original nopCommerce source code. Such changes would have to be made after each version upgrade.
12 years ago
bojan.hrnkas wrote:


3. I read code first supports DRY (Don't repeat yourself). Through inheritance child entities would only need the new features mapped. I'll need to find the article again.

But given  the scenario you provided, what kind of value would changing to XML add?

Alright, if you can map new features in an extra file, that renders my post invalid.
My concern was about having to change the original nopCommerce source code. Such changes would have to be made after each version upgrade.


http://blogs.msdn.com/b/efdesign/archive/2009/10/12/code-only-further-enhancements.aspx

Here is the article I was referring to, sorry I didn't post it in my first response. One more thing to note about the xml

1. With xml & fluent you would be able to use a partial class on your entity (avoid merge conflicts on the domain model).
2. Moving mapping from a fluent map class into xml just moves the merging issue from  C# class into an xml file. In my opinion there would be no improvement for handling update merges by moving class mappings into xml.
12 years ago
skyler.severns wrote:


http://blogs.msdn.com/b/efdesign/archive/2009/10/12/code-only-further-enhancements.aspx

Here is the article I was referring to, sorry I didn't post it in my first response. One more thing to note about the xml

1. With xml & fluent you would be able to use a partial class on your entity (avoid merge conflicts on the domain model).
2. Moving mapping from a fluent map class into xml just moves the merging issue from  C# class into an xml file. In my opinion there would be no improvement for handling update merges by moving class mappings into xml.


You are absolutely right. XML is not the best option. However, I was referencing multiple XML files for same entity, which doesn't necessarily make things simpler. But with this "don't repeat yourself", XML is out of the question.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.