let's consider a web application built using MVC concept. If my application generates some chart images dynamically based on the user input and a database I wish to know which component the image generation process will belong to: controller or view?
It's controllers job to generate the image and the view component to display it?
yes, but i would make a class that generate the chart which would be invoked by the controller
in short, yes you are correct.
You are correct, a controller should generate the image and the view should display it. This would most likely be handled by a setting the "src" attribute of an image to a controller/dispatch that streams binary data, but it's up to you how exactly you implement that.
The controller is responsible for coordinating the generation of the image. The image can be generated by an HttpHandler, some other component capable of generating the stream or static resource that should be returned.
As an addition to the other answers, here's an example.
Related
I'd like to use Nightwatch's Page Objects system for UI components used across our app. Because nightwatch has their own way of reading/initializing them, I don't see a way of properly extending/re-using them.
For example I want an DateInputPageObject for "date fields". It would identify the label, input, date picker, etc.
I'd use it on any page with a date input field.
I would also like to extend page objects. For example, class FooModal extends Modal. The ModalPageObject would define selectors for elements all modals have - the overlay, container, close button, etc.
I can't find any way to do this in nightwatch, is it possible at all?
The problem is not with nightwatch per se as it's just following the basic structure of page object model BUT that is a very good question and it brings out one of the drawbacks of page object model.
Page object model has been around for some time and the problem with that is that it doesn't serve the needs of modern web applications that use component libraries & living style-guides and re-using components.
Personally I found it easier to use a global json file with all the components structured based on their type. e.g. labels, fields, buttons, etc.
I have just setup a new Sitecore 6.6 MVC application and all is going well.
I need a breadcrumb trail and found this:
http://nuget.org/packages/MvcSiteMapProvider
I have set it up and it renders the
#Html.MvcSiteMap().SiteMap() correctly
but
it doesn't render anything for bread crumb:
#Html.MvcSiteMap().SiteMapPath()
If I debug into the SiteMapPathHelperModel.cshtml I can see that there are no nodes in my Model.
First question is, can and should I use:
http://nuget.org/packages/MvcSiteMapProvider
in MVC with Sitecore.
Second question is:
If you think it is ok to use this, do you have any idea why it doesnt render my bread crumb but it renders the menu?
I have never used SiteCore, so I don't know how it is set up exactly. However, MvcSiteMapProvider is flexible and can accommodate many scenarios.
The SiteMapPath() will render if you navigate to one of the URLs that are registered in the Mvc.sitemap XML file. Note that in most cases you need to register them with a controller and action attribute set. The whole principle is based on matching a unique node within the sitemap to a route, so you need to ensure that both the node and the route of the request have matching RouteValues dictionaries.
See the MvcMusicStore demo in the source code download if you need to see a working implementation to get started, or have a look at this tutorial:
http://www.shiningtreasures.com/post/2013/08/07/MvcSiteMapProvider-40-a-test-drive
Currently, in our deployment we have a abstract type Component which represents a part of our Page, basically an element such as a Question, which can have multiple choice, a text box or any other form of answering it, or a Video that users can play, basically a shard of a page that is interchangeable, basically, our design was to have a specific area in our website which would be rendered through a list of Components, we tried at first to have each "Page" object have a List of Components, and each Component would have a method render that would return a Spring View, we thought we could iterate over the list and somehow mash the views together.
We also tried using XSTLViews with no more success, it seems to be more of a design problem and our abuse of the way Spring MVC should be used.
We will really be glad to receive any advice/tips/corrections about how to do it right and maybe some corrections about misconceptions we might have.
It sounds like you're more than half way to a design that uses AJAX to build your page. You're trying to mash up a bunch of Components into one request. What if you returned a container page which then requested/inserted a block of html for each URL it was given a render time. Each of these URLs would refer to a single component. It might be a performance hit if you are including a lot of these Components, but it seems to fit the design.
I'm trying to render a view, defined in a module, in the main site homepage (~/) as it's main content. If the user is not authenticated, i need to show a login/register view instead.
The logged-in view lives in one module (Product Module) and the login/register view lives in another (Account Module). The logged-in view requires a service call to fetch data based on the user's products. I'm currently using standard mvc to render these views and fetch the data they require in their controllers.
Can this be accomplished by treating these views as shape templates? If so, are there any examples of pulling in views to the homepage like this? Or is there a better way of achieving this?
I have tried implmenting IHomePageProvider to return my own homepage ViewResult within the Product module, but without any success.
Cheers.
First, you might want to look into widgets and layers. You could define a layer for authenticaed users, and one for anonymous users, and attach widgets to those layers to achieve what you want. That might be the best way for you to accomplish this. Look in the Orchard docs for examples on how to do this.
I have done a similar thing before using custom controller and a lot of custom logic. Because of my specific requirements widgets and layers would not work for this. All the content on the page needed to change depending on some inputs, and widgets and layers were not going to be well suited for this. What I did was create a custom controller, and a corresponding Route with a high priority (so the Route takes precedence over any others that want to be the home page). I didn't mess with IHomePageProvider at all.
In the controller action I pulled the data necessary, and created the shapes I wanted, and then returned a result like this: return new ShapeResult(this, homePageShape);
homePageShape is constructed like this, right before the return statement:
// Create personalized home page shape:
var homeShape = _orchardServices.New.CustomHome(
SomeShape1: someShape1
, SomeShape2: someShape2
, SomeModel1: someModel1
...
);
This creates a shape called CustomHome, and orchard will automatically look for a template called CustomHome.cshtml in the views folder of your module.
I created several shapes (all the "someShapeX" vars you see above). Mostly they are created from content parts via the BuildDisplay() method. The content parts are queried using IContentManager, and the shapes are created like this (this example is for a slide show shape):
dynamic sliderShape = _contentManager.BuildDisplay(sliderPart, "Detail");
You can put logic in the controller to build the shapes you want depending on whether or not the user is logged in. In CustomHome.cshtml you would render a shape like this:
#Display(Model.SomeShape1)
I am writing a helper class to query my Zenfolio feed, return and display the images. Right now this code is split between a viewmodel and code in my controller. I want to pack it up into a helper class. Would all the code go into the helper or do i still split the code among different class with the helper only responible for generating the html? I have googled but not found an answer to my question.
Within the MVC pattern there is a clear separation between Model (data), View (html) and Controller (what gives the Model to the View).
To answer your question, No. Load your models in your Controller. Display them in your View. Html Helpers should only generate html for your view.
You may want to consider using a DisplayTemplate, which allows you use the same View template for every model of a particular type.
I wouldn't do any data access from the view. This sounds like a good use case for an action, and reusing code via the RenderAction method. You can mark the action as a child action using the [ChildActionOnly] attribute, which ensures it can't be invoked directly from the HTTP request, and return a PartialView result.
HTML helpers should really be used to generate HTML tags from data taken from the ViewData or Model (i.e. your view model in this case).
Data access in an HtmlHelper is only pain.
I've had the misfortune to inherit a project that had ad-hoc SQL placed into the HtmlHelpers by the 2nd developer on a project. The HtmlHelpers were beautifully written by the first developer, and the ad-hoc SQL pretty much nullified all of the time and effort put into having an service oriented architecture, having an ORM (the 2nd level cache became worthless), the unit of work pattern(transactions, worthless), and every aspect of design. Eventually, this 2nd developer had to make larger and larger HtmlHelpers so that different elements could share access to the data.
This was originally done for a display mode, and editing was accomplished through a pile of ugly custom javascript. All told, when the page rendered, it made 600 synchronous calls to the database.