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
Related
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).
I have an application that allows the user to drill down through data from a single large table with many columns. It works like this:
There is a list of distinct top-level table values on the screen.
User clicks on it, then the list changes to the distinct next-level values for whatever was clicked on.
User clicks on one of those values, taken to 3rd level values, etc.
There are about 50 attributes they could go through, but it usually ends up only being 3 or 4. But since those 3 or 4 vary among the 50 possible attributes, I have to persist the selections to the browser. Right now I do it in a hideous and bulky hidden form. It works, but it is delicate and suboptimal. In order for it to work, the value of whatever level attribute is on the screen is populated in the appropriate place on the hidden form on the click event, and then a jQuery Ajax POST submits the form. Ugly.
I have also looked at Backbone.js, but I don't want to roll another toolkit into this project while there may be some other simple convention that I'm missing. Is there a standard Rails Way of doing something like this, or just some better way period?
Possible Approaches to Single-Table Drill-Down
If you want to perform column selections from a single table with a large set of columns, there are a few basic approaches you might consider.
Use a client-side JavaScript library to display/hide columns on demand. For example, you might use DataTables to dynamically adjust which columns are displayed based on what's relevant to the last value (or set of values) selected.
You can use a form in your views to pass relevant columns names into the session or the params hash, and inspect those values for what columns to render in the view when drilling down to the next level.
Your next server-side request could include a list of columns of interest, and your controller could use those column names to build a custom query using SELECT or #pluck. Such queries often involve tainted objects, so sanitize that input thoroughly and handle with care!
If your database supports views, users could select pre-defined or dynamic views from the next controller action, which may or may not be more performant. It's at least an idea worth pursuing, but you'd have to benchmark this carefully, and make sure you don't end up with SQL injections or an unmanageable number of pre-defined views to maintain.
Some Caveats
There are generally trade-offs between memory and latency when deciding whether to handle this sort of feature client-side or server-side. It's also generally worth revisiting the business logic behind having a huge denormalized table, and investigating whether the problem domain can't be broken down into a more manageable set of RESTful resources.
Another thing to consider is that Rails won't stop you from doing things that violate the basic resource-oriented MVC pattern. From your question, there is an implied assumption that you don't have a canonical representation for each data resource; approaching Rails this way often increases complexity. If that complexity is truly necessary to meet your application's requirements then that's fine, but I'd certainly recommend carefully assessing your fundamental design goals to see if the functional trade-offs and long-term maintenance burdens are worth it.
I've found questions similar to yours on Stack Overflow; there doesn't appear to be an API or style anyone mentions for persisting across requests. The best you can do seems to be storage in classes or some iteration on what you're already doing:
1) Persistence in memory between sessions/requests
2) Coping with request persistence design-wise
3) Using class caching
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.
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 am looking for some general wisdom here.
I am looking for an elegantly simple way to limit the number of rows in a table that are presented on a page with a "view all >>" to get the whole table presented in the view. I considered all of the following,... some in combination:
two different partials,... one that lists a limited number of rows with a "view all >>" link at the bottom and a second that lists all with a "collapse >>" link at the bottom.
using jQuery
a css solution
ajax
Any links and / or snippets would be helpful in addition to your rationale for choosing one over another. I would prefer to minimize server / database requests without creating a voluminous coding monument to ingenuity of the programmer (me) :=]
Thanks!
UPDATE: Look here to see code written before that could be adapted. Many thanks to Neal for the jsfiddle.net resource.
A GREAT solution for big tables is a Grid. My grid of choice is DataTables
Grids solve a lot of problems: sorting, paging, filtering, ajax loading, and showing/hiding results. It's likely you're only talking about the limiting portion of the equation, but I'd submit that ALL the features have a value in interfaces, so they're all worth looking at.
Setting it up is easy and you have three options for data:
Build a proper HTML table with <thead> and <tbody> tags. The grid interprets the DOM and styles accordingly.
Provide a valid JSON string with table data. DataTables builds the HTML for you.
Supply JSON via AJAX. This also allows you to "pipeline" data to lookup data ahead of and behind the desired.
Datatables is JQuery driven, so you'll have to include Jquery and the DataTables code. There is also a bit of CSS to make things "pretty" That's it....pretty easy. Once you get the hang of it, producing a new DataTable from scratch takes 2-3 minutes. Considering the features, that's a minimal investment in your UI.
As to performance, I have a DataTable handling 2.5 million records without fail. It utilizes JSON pipelining, paging, sorting, and filtering (and a well-indexed MySQL DB) to maintain acceptable performance.