How can I dynamically manage FAQ page without any changes in Nop Code?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
11 anni tempo fa
I want to add dynamically manageable FAQ page in my current Nop. And It must add some questions and answers with its CRUD operation. But I don't want to edit my current Nop code. Is there any way I can manage it?

Thanks in advance.
11 anni tempo fa
krutal wrote:
I want to add dynamically manageable FAQ page in my current Nop. And It must add some questions and answers with its CRUD operation. But I don't want to edit my current Nop code. Is there any way I can manage it?

Thanks in advance.


Create a Widget. :P
11 anni tempo fa
What do you mean by create a Widget?
How Can I create it?
What are its benefits?
P.S advice me.
11 anni tempo fa
krutal wrote:
What do you mean by create a Widget?
How Can I create it?
What are its benefits?
P.S advice me.


A Widget is a type of plugin in nopCommerce. By creating a Widget, you can place custom content at different ZONEs of nopCommerce, and you can manage the Widget at the backend. By creating a Widget, you can keep nopCommerce source code intact, yet still having the features that you want. You can try https://www.nopcommerce.com/docs/77/how-to-write-a-nopcommerce-plugin.aspx :)
11 anni tempo fa
There isn't really anyway around it, you will need to edit some Nop code regardless of the path you take.  A widget requires you placing it into a page.  I'm not entirely sure if a plugin would be the same or not, but I'd be willing to say yes you would have to make some changes to the code.  I would suggest possibly creating your FAQs in a page by itself with a link either in the header or front page.  A widget on the front page seems like it would be too large in my opinion but maybe not pending the amount of FAQs you would have.

In any case, there is no escaping editing the Nop code.
11 anni tempo fa
chajo10 wrote:
There isn't really anyway around it, you will need to edit some Nop code regardless of the path you take.  A widget requires you placing it into a page.  I'm not entirely sure if a plugin would be the same or not, but I'd be willing to say yes you would have to make some changes to the code.  I would suggest possibly creating your FAQs in a page by itself with a link either in the header or front page.  A widget on the front page seems like it would be too large in my opinion but maybe not pending the amount of FAQs you would have.

In any case, there is no escaping editing the Nop code.


No. No change in code is needed. At most what we have to change is the View (in case you want to place the widget in a zone that is not specified by default in nopCommerce).

A Widget has 2 important actions, the Public Info action, that is called to display the widget in the front end; and the Configure action that is called to display the configuration view at the backend. You can create a widget, that the Public Info display a link. And the link (or rather the Widget itself actually) be placed in an appropriate ZONE (let say the Main Menu). Then, you have the RouteProvider.cs, which you can provide any route. So what we can do is: to create an Action (and the View, of course) WITHIN the Widget plugin, and register for the route like:

            routes.MapRoute("Plugin.Widgets.Faq.Details",
                 "faqs",
                 new { controller = "WidgetsFaq", action = "Details" },
                 new[] { "Nop.Plugin.Widgets.Faq.Controllers" }
            );


Then, make the Public Info view display a link to the route using @Url.RouteUrl. Thus, the Widget will now link to another Action that is also contained within the Widget. :)
11 anni tempo fa
...  Changing the View and Route Provider is a change to the current code.  Hence why I say you will have to make some changes to the code...  *sighs while shaking head*

It also depends on if you're going to reuse this widget or not.  If not, a simple PartialView might be just as easy.  You would need to tweak the View you are going to place it in naturally, but that is the same if you're adding a widget somewhere also.  I have a custom PartialView I made for the homepage that targets a specific user role to alert them about actions they need to take.  It was quick and simple to make, maybe faster than a widget at that (I looked into making one but decided against it since it would be a one time deal).
11 anni tempo fa
chajo10 wrote:
...  Changing the View and Route Provider is a change to the current code.  Hence why I say you will have to make some changes to the code...  *sighs while shaking head*

It also depends on if you're going to reuse this widget or not.  If not, a simple PartialView might be just as easy.  You would need to tweak the View you are going to place it in naturally, but that is the same if you're adding a widget somewhere also.  I have a custom PartialView I made for the homepage that targets a specific user role to alert them about actions they need to take.  It was quick and simple to make, maybe faster than a widget at that (I looked into making one but decided against it since it would be a one time deal).


RouteProvider.cs can be added to plugin, in fact quite a number of plugins HAVE IT, so I don't see why that is considered CHANGING CODE. And strictly speaking, View contains MARKUP not CODE. Plus, you MIGHT or MIGHT NOT change the view, if you have the corresponding ZONE in place, then you DON'T NEED. The Top Menu (ROOT\Views\Common\Menu.cshtml) for example, already has the ZONE defined:

@Html.Action("WidgetsByZone", "Widget", new { widgetZone = "header_menu_after" })


chajo10 wrote:
but that is the same if you're adding a widget somewhere also


No. Adding a Widget is done at the backend, and nopCommerce MOST PROBABLY has the required zone already as explained above.

chajo10 wrote:
I have a custom PartialView I made for the homepage that targets a specific user role to alert them about actions they need to take


What he need is not a STATIC information. He needed something that can be edited at the backend. He needs to DYNAMICALLY MANAGE the FAQs (read: database), and a Widget is the BEST FIT in this case.

chajo10 wrote:
(I looked into making one but decided against it since it would be a one time deal)


I have already made a few plugins like this. Totally manageable for ANY COMPETENT programmer.

chajo10 wrote:
*sighs while shaking head*


Please mind your manner, even if you do not agree with other people. :)
11 anni tempo fa
Somebody sure gets offended easily and likes to troll.  :)

wooncherk wrote:

RouteProvider.cs can be added to plugin, in fact quite a number of plugins HAVE IT, so I don't see why that is considered CHANGING CODE. And strictly speaking, View contains MARKUP not CODE. Plus, you MIGHT or MIGHT NOT change the view, if you have the corresponding ZONE in place, then you DON'T NEED. The Top Menu (ROOT\Views\Common\Menu.cshtml) for example, already has the ZONE defined:

@Html.Action("WidgetsByZone", "Widget", new { widgetZone = "header_menu_after" })



Yes, RouteProdiver.cs can be in plugins and quite a few have them.  Is it needed, not necessarily.  Arguing Views are not code is kind of pointless since Razor was built around making interjecting C# code into html easier.  Look at your Html.Action.  That is code made for Razor that is using some C#.  So is it code?  Seems like it, so rethink the statement you aren't changing code.

wooncherk wrote:

No. Adding a Widget is done at the backend, and nopCommerce MOST PROBABLY has the required zone already as explained above.

What he need is not a STATIC information. He needed something that can be edited at the backend. He needs to DYNAMICALLY MANAGE the FAQs (read: database), and a Widget is the BEST FIT in this case.


Yes, his info is static.  Should it be on the homepage, doubtful unless the FAQs are very, very short.  In that case, it would be a page, that use, could use a widget.  Why you would want to build a widget into a lone page, I don't know, but whatever makes you happy.  Btw, his info could be edited on the backend as well for this if built out.  I've not run across where it can be edited on the backend for widgets thus far, so yeah, it's possible if it makes you happy.

wooncherk wrote:

I have already made a few plugins like this. Totally manageable for ANY COMPETENT programmer.


Lol, so much trolling.  Do you know for certain I haven't made plugins?  You might be disappointed if so.  But whatever makes you happy.  :P

wooncherk wrote:

Please mind your manner, even if you do not agree with other people. :)


It's manners, not manner...  As for mind your manners, you're a shining example.  Thanks!  :P

I did not personally attack you originally and simply said that is changing code after you said it was not.  For you to fire back so harshly makes me wonder why you would be so infuriated by something that should not have mattered.
  
Btw, people do come up with different ideas on a subject and can/will criticise one another about said ideas.  Learn to deal with that aspect of life.
11 anni tempo fa
chajo10 wrote:

Yes, RouteProdiver.cs can be in plugins and quite a few have them.  Is it needed, not necessarily.  Arguing Views are not code is kind of pointless since Razor was built around making interjecting C# code into html easier.  Look at your Html.Action.  That is code made for Razor that is using some C#.  So is it code?  Seems like it, so rethink the statement you aren't changing code.


So I say you have not understood my point. In my case, it is necessary, because we are linking a to a new page (read: Action), and we want a nice route. Let me explain again in case you are lost:

1. We have the Public Info action, which will contain just a link to our Action in point 3.
2. We have a Configure action, which can provide a mean for you to manage (read: database CRUD) the FAQs
3. Then we have an Action that is, let say, named Faq, and a corresponding View that is named Faq. This is the place that the FAQs will be shown, not the Public Info action. And we can use RouteProvider to provide a nice link to this page, let say http://site.com/faqs. Clean solution. The Faq action will do the heavy lifting of pulling data from the DB.
4. Back to the Public Info action (or rather, the Widget itself). It will be added to, let say, the "header_menu_after" zone, then we have a link to the page in POINT 3.

chajo10 wrote:

Yes, his info is static.  Should it be on the homepage, doubtful unless the FAQs are very, very short.


No. His info is DYNAMIC. Read his very first post: krutal wrote:
I want to add dynamically manageable FAQ page in my current Nop


chajo10 wrote:

Arguing Views are not code is kind of pointless since Razor was built around making interjecting C# code into html easier.  Look at your Html.Action.  That is code made for Razor that is using some C#.  So is it code?  Seems like it, so rethink the statement you aren't changing code.


You have a point here, criticism accepted. Anyway, just as I've explained, you can add a widget to ANY zone. You only need to change if there is no such zone defined. So yeah, WE ARE NOT CHANGING CODE! :)

chajo10 wrote:

In that case, it would be a page, that use, could use a widget.  Why you would want to build a widget into a lone page, I don't know, but whatever makes you happy.  Btw, his info could be edited on the backend as well for this if built out.


Read POINT 3 to learn how to attach a page to a plugin, and have other place of nopCommerce link to it.

chajo10 wrote:
I've not run across where it can be edited on the backend for widgets thus far, so yeah, it's possible if it makes you happy.


Based on Point 2 in my explanation above, you should now learn how it can actually be done. Otherwise, you might want to learn at https://www.nopcommerce.com/docs/75/plugin-with-data-access.aspx


chajo10 wrote:
Lol, so much trolling.  Do you know for certain I haven't made plugins?  You might be disappointed if so.  But whatever makes you happy.  :P


You may have made 1000 plugins, but the information you've provided that "a Widget can't do this or cant do that" just doesn't make sense.


chajo10 wrote:
It's manners, not manner...  As for mind your manners, you're a shining example.  Thanks!  :P

I did not personally attack you originally and simply said that is changing code after you said it was not.  For you to fire back so harshly makes me wonder why you would be so infuriated by something that should not have mattered.
  
Btw, people do come up with different ideas on a subject and can/will criticise one another about said ideas.  Learn to deal with that aspect of life.


The fact that you corrected on my typo means you have lost your sense. I am open to criticism, but please, give fact.

Plus

chajo10 wrote:
*sighs while shaking head*


is very offensive, in case you need to know. :)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.