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.
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 written python code that analyses two text sources and compares them.
I'd like to implement this dynamically via two text boxes that a user could either type into or manually upload. I have already begun coding this using HTML. Would it be better to implement a widget or the models instead to make the text area boxes?
Edit:
I wrote this question when I was just figuring Django out, so forgive me if it sounds confusing. But everyone starts somewhere. I'm unable to delete the question as contributions have been made already. YouTube courses proved helpful in learning the basics, if any beginners stumble upon this.
You use a form object. Django has form objects (https://docs.djangoproject.com/en/2.0/topics/forms) that take a model and translate it into html elements. So I guess in a way, you implement the model but I want to stress that that's not actually what's happening from a technical standpoint. A better way to say it is that you're implementing forms. The reason I stress this so much is so that you understand what's really going on so that you don't have misunderstandings that end up costing you in code clarity and readability.
So to answer your question, you can implement django forms to do this very easily. The way you implement it depends on your models and how they are designed since the forms use the models to create the right html form elements. If you're dealing with one model that will be instantiated by the form input, create a model form. This will take the input from the form and create your model instance. If you're dealing with one form that uses multiple models, then use a generic form. In this case, you will have to write your own save method that does the actual logic of the form.
One other thing to add... No matter what, your end result will always be a widget on the HTML in the end. Django forms translate a model class into a form element with input elements. If you didn't use Django forms, you would still do the translating, but you would have to do it from scratch.
I hope this helps and that I correctly understood your question.
Today when I searched on the internet I saw the View first approach in web development of Lift framework. Can somebody tell me the differences between view first and MVC approach ?
Thank you very much
View first is based not on a model and a controller, but mostly interested in the view. Many problem domains do not neatly compose in controllers and models. Think about a ecommerce site, the shopping cart exists on all pages, but should every controller control it? Personally in MVC too much of my time is spent thinking about how to logically make the problem fit into MVC than just coding. View first takes away this controller / view / model and instead just has a view which in Lift can call "snippets". It is almost a superset of MVC since if you wanted you could only have a single snippet per page, but Lift allows you to do much more. Snippets can be cross cutting concerns or very page specfic logic.
From the lift website..
Lift is different [from MVC]. For HTML requests, Lift loads the view first and builds your page from the view. Lift also supports REST style requests for non-HTML data. (See 11 on page 1↑) “Why?” Because complex HTML pages rarely contain a dominant piece of logic... a single controller... but contain many different components. Some of those components interact and some do not. In Lift, you define the collection of components to be rendered in the resulting HTML page in the view.
When your using lift, you basically have a view(page) and from this you could incorporate any snippet(app) that you have without much of the antics you'd normally have to do in an MVC framework/environment.
Basically you don't have to choose what the most important thing on the page is just what you want to add to a page and then add it.
I'm new to MVC3 (and MVC in general) and looking for a bit of advice. Pointing me in the direction of some good articles or tutorials would be good enough I think. I'm a bit familiar with the concept of MVC, and I've been a c# programmer (hobbyist and partly professional) for a while now.
The issue I have is that I have an object (call it "Game"), which has a List<T> as a property (call T "Player"), and I want the user to "select" the player to add them to the Game.
All players would be managed in another part of the application, so there is no need to think about "managing" the master player pool at this point.
I'm looking for a best practice for:
adding custom objects to a list that of n length while on a page.
Searching for and selecting a custom object in the first place.
I can do the standard pages for the database access so that's not a problem. In asp I would have just done something like a wizard and managed everything through postback on the page, but I want to try and keep to best practice where i can for this project.
Any pointers welcome, also looking for some good physical books to buy on MVC.
If I understand you correctly you want two elements within the page, a player search (over all players) and a list of players already added to the game.
For the player search you want to use a bit of jQuery to hook up an actionResult that returns a JSON result of your player results. You can then display these results without having to leave the page, in appearance much like an AJAX post in webforms.
You have more options for how you add the player to the game, depending on if you want to add more than one at once, or want a backout stage (so you can "add" players and then cancel out and they won't be added).
the option I think would give the most seamless interface would be a jQuery/javascript call to an action method which datawise adds your player to the game, and use jQuery to add the element to your players in the game on the page.
For the adding of a player in your controller you could return a bool in a JSON result, just you have confirmation that the player was successfully added to the list.
For reference: This is quite an old article but highlights the power of working with jQuery and MVC quite nicely I think http://andreasohlund.net/2008/12/21/asp-net-mvc-jquery-true/
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.