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.
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.
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.
In a typical business application it is quite common to have forms that are used for searching.
Some basic features are:
A pane that contains the search criteria
A grid to display the results
Sorting on the grid
A detail page that opens when an item is selected in the results grid
What other features would you expect in a business application's search functionality?
Maybe it's a bit trite but there is some sense in this picture:
removed dead ImageShack link
Do it as it shown at the second example, not as at the 3rd one.
There is a well known extreme programming principle - YAGNI. I think it's absolutely appliabe to almost any problem. You always can add something new if it's necessary, but it's much more difficult to remove something what is already exist because someone already uses it even if it's wrong.
How about the ability to save search criteria, in order to easily re-run a search later. Or, the ability to easily, cleanly, print the list of results.
If search refining is allowed (given a search result, limited future searches to the current results), you may also want to add a breadcrumb system, so that the user can see the sequence of refinements that lead you to the current result-set -- and by clicking on a breadcrumb, return to a previous refinement stage.
Faceted search:
(source: msdn.com)
This is displayed in the area in the right ellipse. There are filters and the engine shows the number of results that will remain after aplying the filter. This is very useful and can be done without pain in some search engines, such as Apache Solr. Of course, implement this only if filters make sense in your task.
Aggregate summary info, like total(s), count(s) or percentages.
One or more menus, like right click context for the grid, a ribbon or menu on top.
Your list for the UI elements is kinda good. Export, print (asking them whether it is really necessary to print this?), category/tag and language selection is worth to consider. Smart and working pagination (don't forget ordering).
Please do not force a search to open in a new (or even worse, always in the same window). Links of search results should be copy-pastable (always use GET),
But it really matters to have a functional (i.e. a really good) algorithm. Mostly I google company websites, because their search engine is, cough, awwwwkward. Looking for a feature chart, technical spec, pricing etc. one is not interested in press releases and vica-versa.
Search engine providers offer integration into company websites.
Use Auto-complete wherever possible on your text input fields.
If using selects or combo boxes with related information try and use chain selects to organise the information.
Where results depend on location try and serve relevant results.
Also remember to keep the search form as simple as possible even down to one text field. To refine the search you can have an alternate form as an "Advanced Search interface".
Printing, export.
A grid to display the results
Watch out not to display results a user is not authorized to see (roles / permissions / access rights).
A detail page that opens when an item is selected in the results grid
In case a user attempts to circumvent the search page links and enter some document directly, again, check out for permissions.
Validation, validation, validation.
It should be very hard, near impossible, for me to run a query that makes no sense. ie, start date occurring after an end date.
Export a numerical dataset (even if it only has one numeric column - so just make it so by default) to CSV for import into Excel (people love this function, even if only 1% of users seem to use it with any regularity. Just ask yourself when's the last time you highlighted something for copy-n-paste. Would it have been easier to open a CSV?
Refinable searches (think Google's use of site: -). People who use the search utility a lot will appreciate this. People who don't won't know it's not there.
The ability to choose to display 1 records, 5 records, 100 records, 1000 records, etc. "Paging" I believe is what we most commonly call it ;).
You mentioned sortable grids. Somebody else mentioned auto-sum or auto-count. Those are good if (once again) you have largely numeric data. But those are almost report-oriented functions.
Hope this helps.
One thing you can do is have a drop down of most common searches in plain english. e.g. "High value sales in New York in last 5 days". This is the equivalent of user selecting an amount, the city, date ranges etc. done conveniently for them.
Another thing is to have multiple search criteria tabs based on perspective of the user. Like "sales search", "reporting search", "admin search" etc.
ALso consider limiting the number of entries retrieved in the search and allow users to do more narrow searches. This depends on the business needs however.
The most commonly used search option listed first and in a prominent location.
I think your requirements are good. Take a cue from Google. Google got it right. One text box where you type whatever you want, and your engine spits out the answers. Most folks will try this, and if the answers are good enough, then that is what they will use. In the back-end, you'll probably want to flatten all of the data into a big honkin' table and then index it or use a SQL query with "LIKE" in it.
However, you will probably want to allow the user to refine the search. For this, have a link to "Advanced Search" and use a form there to specify filter criteria. This lets the user zero in on the results if basic search is not good enough. For the results on th is page, you will certainly want to have sorting on key fields, but do it after you have produced the initial result set.
It depends on the content that you are searching for.. make it relevant :) Search always look easy but can be incredibly difficult to get right.
Not mentioned yet, but very important I think - a search that actually works. This item is often neglected and makes the rest a bit moot.
I have a couple specific needs for my search and I'm interested to get people's opinions on what search approach makes the most sense. Based on my explanation below, would you recommend that I use basic sql queries? Or step up to a more advanced search solution, like Sphinx?
I have two models that I want to search in: products and varieties.
product has_many :varieties
variety belongs_to :product
I need my search to recognize the relationship between products and varieties. However, varieties do not have their own existence on the site. So, when a user searches for a variety that's in the system, I need the search to return the corresponding product page on which the variety resides.
For example, let's say that the product is ball and the variety is bouncy. If a user searches for 'bouncy', I want the search to return the ball/show view.
The other tweak involves the results. If there's only one result for a given search, I want to render the product/show page. However, if there are multiple results, I want to render the product/index page, displaying the multiple results. My dataset is a pretty limited universe, so I think it's going to be fairly common that we have only one result.
Those are my requirements. Can I satisfy these requirements with standard sql queries and conditions? Or would you recommend a more advanced search approach?
Thanks!
Either solution will satisfy your requirement, but you can satisfy it with standard SQL queries only if your dataset is small. In that case, a DB index on the searched queries is important. You could take a look at scoped_search which I've used for small projects and gets the job done.
If you have a big dataset and plain SQL queries slow you down, sphinx (and thinking-sphinx) is the way to go. The only disadvantage of this approach is having to monitor and maintain another daemon, although it is very stable and lightweight. This solution is also very easy to implement, and there's a good community around thinking-sphinx.
Lastly, you may consider your database's full text search capabilities. If you are using PostgreSQL, tsearch is a great solution because it is very fast and built into your database process. There are a couple of Rails plugins for interacting with it: acts-as-tsearch and tsearchable. Try them out and see which one feels better to you.