If I have a shop that displays a bunch of products and I get these products returned from the database as an array, is there a specific way that you can display this data using YII templates or is it sufficient to simply loop through the array and print it out in "divs" as needed?
I know if I just spit it out in DIVs, it would work, but is it the "correct" way to do it according to the framework?
For this there are zii widgets, and also many extensions.
I think for a store CListView will be a good start. There are many wikis that explain a lot about CListView.
You can easily extend it and add functionality.
Zii widgets provide pagination, sorting, and custom styling too, when used alongwith a data provider.
Related
I need to create a system to store and serve information about survey questions. Given a variety of questions, field types and field arrangments, I need to serve the data needed by the front end to display the fields.
One of my big concerns is layout information. I'm not sure all the ways the fields can be arranged. At a minimum, I need to support things like two text fields appearing on 1 line, with a third on the next line. Or 6 multiple choice answers arranged in 2 columns of 3 rows.
Is it appropriate to store this layout information in my database, and to serve it with the question/field data? I think these are my 3 options. Any thoughts on these options would be very helpful, or suggestions for other things to consider:
I could store indicators that the question uses a column layout, and give each field hints as to what row/column it is in.
I could store something like CSS or mustache templates to define the layout.
I could leave this entirely to the front end. I could return the survey data and expect the front end to handle any layout concerns
The general answer/advice i would give is no. If you put any layout information in the database you will make it very hard to build new functionality, extend your product offering in the future, support multiple front ends (mobile, progressive web app, main website) and perform redesigns in the future.
I would go with option C. Leave it to the front end. You can easily store the 'type' of question which may map to a template in the front end maybe, this will allow the different front ends to render that type of template as the design needs. And will allow you to easily evolve the design in the future, the last thing you want if you desire to do a redesign is to need DB update scripts to try and 'fix' css and display data.
Obviously i lack the full picture of what you are trying to achieve, the road map of your product and your future ideas, but i honestly cant think of a scenario where storing css in the DB would be a good idea.
I hope you find this useful, I would be keen to hear how you decide to progress with this.
I am trying to code a medium sized full web application based off dojo.
I have a basic BorderContainer that is placed at the document.body.
In order to make code maintainable and easy to read, I want to put fully contained widgets/modules in each of the sections. That can be simply added by a couple lines such as...
var topTabs = new TopTabs();
top.addChild(topTabs);
And then I want to stitch them all together so that they can invoke work in each of the other widgets, in order to follow the MVC model.
So for instance, one example that I would like to insert the following widget that is fully contained into the top section that looks something like...
So my question is....
What is the best way to create these fully defined and encapsulated widgets/modules?
Since my widgets will also contain other Dijits, then are template based widgets the route to go? Or is it better to create widgets/modules that are purely programmatically defined?
Thanks
Depends how much you are familiar / comfortable with declarative/html (templated) versus programmatic/javascript. You can definitely go both routes;
I seldom use templates, which are static by nature and mean two set of entities in two languages, usually two files, to account for. Besides, with dojo/dom-construct & dojo/dom-style, I have an effective dynamic replacement to html templates, allowing to build self-contained complex widgets
jc
Your going to want to read about making custom dijits (widgets) - https://dojotoolkit.org/documentation/tutorials/1.9/recipes/custom_widget/
templates vs programmatic is more of a personal choice. templates are much easier for a UX (non dev) to work with. i like to use templates as it reduces the clutter in my js files i prefer to keep things separate logic (js), style (css), and structure/layout (html).
What is the best way to get data from Rails 3 to some of Kendo UI's data intensive widgets (mostly grid and graphs)?
Lets say I have a Rails model which has data I want to show in Kendo's grid. I imagine I will be passing that data via json. But there seems to be many approaches to passing json data (gon, backbone.js,etc). There is also the rails api approach (but I need the full rails for the other pages).
I was about to sit down and learn backbone.js. Is this a good approach?
Thank You
You just need to create an action that will serve your data as JSON. You do not need to use other JavaScript libraries. Take a look at this project, I think you might find it useful.
I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.
Looking at Knockout examples, there is no real need for adding IDs to HTML elements. Creating a large form without the IDs seems to make it easy to maintain.
Though, this creates a problem with Selenium HQ. There is no way to uniquely identify elements on the form.
What are the choices? Is there another method for Selenium to select elements created by Knockout?
or will I have to assign IDs to elements?
I have reviewed other knockout and selenium questions. All of them had IDs defined for the HTML elements, when they started.
Thanks
Abhi
Short answer: Add ID's to your HTML elements.
Although you do not need these attributes in order for your website to function, you will make the life of your testers so much easier.
I've encountered the exact same problem in a project where a large ASP.NET MVC 4 application was created, that uses Knockout.js and Selenium extensively. For form elements, I relied on ASP.NET MVC utility methods to generate the output HTML in combination with data-bind expressions. ASP.NET MVC automatically generates unique NAME and ID attributes based on the backing model.
However, in all other cases where I had to render tables, display forms or dialogs, I ended up adding ID attributes to these HTML elements. If you think about it, this is a logical consequence of your requirements. Knockout is awesome because you longer need ID's and NAME's to wire your layout (HTML) and behavior (JS) together. However, other frameworks, such as Selenium, require these ID's to be present.
Yes, you could work your way around it with complicated and bloated XPATH expressions. But this will dramatically decrease the maintainability of your tests. In my experience, adding ID's to hundreds of HTML elements took less than a day and increased productivity of our testers by a manifold.
Remember, it may be nice to develop functional websites with as little HTML as possible. But if this makes your website untestable, you will lose more than you gain. Testability is non-functional requirement, but this does not mean it is not important!
You should add Ids to your html elements. your application will become more complicated and probably you'll need to bind multiple view models to different section on the same page, you'll need Ids. For example in ASP.NET MVC, you'll want to build a partial view to display all products you ordered, and you want to share this partial view all the way through the ordering process, you'll want your binding to this specific partial view section