Quite often we deal with lists of things on our site. These initially get loaded with the rest of the page from the server. However, any updates received we would like to update these lists using Ember.
All of the examples I have seen so far with Ember views deal with controlling content on a page that has always been created purely by Ember. What options are there for dealing with DOM elements that already exist on the page with Ember views?
There has been some discussion around this idea here: https://github.com/emberjs/ember.js/issues/563
In the current situation two approaches come to my mind:
Replace the static rendered list with an Ember.CollectionView as soon as all list items are available to ember as data objects (e.g through ember-data)
Use plain old jQuery to append the latest updates at the beginning / end of the list
I guess it depends on how complex your list items and the updating logic is. If updates need reordering of items and your list needs complex interaction, the first approach using ember might be better suited, although there could be a "flickering" of content while the lists are replaced. The second approach is much simpler but also limited. I would only use jQuery for appending / prepending content. Still, if the lists are simple it would be overkill to even use ember in this case.
Related
This question relates specifically to the new Ember angle bracket component syntax, but also in general to Web Components.
I am working on upgrading an Ember application that is not on the later versions of Ember, and I decided that I would use the Ember 1.13 beta so that I can take advantage of the angle brackets components already.
I have a lot of components that built html hierarchies with other elements than div, such as a table where every tbody/tr/td is a component (for let's say having a form inside a table for manipulating rows) or a list where every li is a component. I was surprised to see that <my-component> is actually generated as <my-component> in the final html, even with tagName property set. Maybe this was unsurprising to every one else, but for me it will be a much bigger change than anything else announced for Ember 2.0. I read a bunch of articles about Web Components and couldn't see any mention of this issue, so maybe it is just a fundamental misunderstanding on my part.
How do you create components (Web/Ember) that are not block level? By restructuring your html to only have block elements as components? By writing a bunch of css to change them to non-block (such as using display: table-row) elements?
The answer is that there is no answer currently. The behaviour of angle bracket components is being worked out and there is an RFC suggesting how they should behave:
https://github.com/emberjs/rfcs/blob/angle-bracket-components/active/0000-component-unification.md
Let's say there exists a presentational component in a project that renders an unordered list (called ListRenderer, perhaps.) We have a couple options of supplying data to any given ListRenderer on a page:
Have a TreeList (or TreeListEx) field on the content item, and have ListRenderer read from it.
Supply a DataSource (or other Parameter) to the ListRenderer via the presentation details.
I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project.
So my solutions tend toward option #2, which gets rid of that problem. It does, however, come with its own bag of questions. Where do I put these various "Lists" for a given ListRenderer to use? To maximize reuse and sharing, I usually create a components directory near the site root that contains all these types of things, if I predict the Lists will be shared. This seems less findable and harder to use for the content author, who suddenly have no idea where the source for their ListRenderer is unless they know how to crack open the presentation details (which is slightly advanced for my average user).
If I feel like Lists won't be shared, and are very specific to the page, I'll put them directly underneath the item in question. This has a tendency to muddle up the content tree, though, and any dynamically generated navigation sublayout then has to check for whether or not an item is an actual page before it generates the link to it. The more I work in Sitecore, the less I use this approach, but it seems easier for the content author. There is much easier access to information when you use this approach.
Is there any industry-accepted way of approaching this problem? It happens in projects all the time, and in my head I struggle to balance technical and content authorship concerns in situations like these.
Great question. I've used all the techniques you mentioned, depending on the audience and specifics of the project. The problem is that, as with all things Sitecore, they are all valid ways of achieving the same goal and you will struggle to find one answer that will work in every situation.
I almost always use #2 as well, but some content author retraining maybe necessary and make sure you add in restrictions to what the content author is able to select as a target. I have (within the same project) structured the items near the root (in a shared content folder) and under the item in question, depending on what I felt would provide the best context.
Also, if other child pages would exist below the item as well as the list items, then I would put the list items in a separate folder (with a common "list items" icon") and re-order it to be the first item for separation and clarity.
If you want to use any kind of personalization and DMS then you will need the ability to switch out the datasource anyway so you shouldn't hard code locations.
You might also (if you have not already) want to consider using:
Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- Useful if you need to restructure your content at a later date
Queryable Datasource Locations
- Useful for multi-site situations when you need to make clones, or setting as the default datasource value in Standard Values when the lists are directly below the item but gives you the flexibility to change it.
I prefer using querable datasources personally, I find the xpath syntax more logical.
As Mark has commented, there is no real industry standard.
I feel like this is something that needs improvement.
Especially when you are using the DataSource option, things become less transparent to the editors and as the size of the site grows, so does the complexity.
All I can tell you is how I would do it, which is most likely much like how you are doing it.
1) For overview pages like news, events and faq items, I will put the items underneath the overview item and use the NewsMover shared source module to auto-create a hierarchy.
2) I will create a Global site that contains items that are shared across sites or pages. DataSource items for components will be put in here.
3) For components that are present on the standard values, I will add a list field to the template (for example, when you display related items on a content page)
Most often it's a logical choice and sometimes it's just a matter of taste.
I'd like to add that I've written a blog post on how to have datasource items created automatically for components that are set on standard values. That might help you if you are using those.
Edit:
"I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project."
Today I've blogged about a method of hiding fields and sections in the content editor if there is no sublayout set on the item that requires those fields, which helps to prevent the mess of having a lot of unused fields on your items.
I'm putting together a website, where one of the pages holds an interactive map. The map is implemented as a big table, where each node is a td.
Now this map takes a while to render, and so, I'd love for the site to be displayed as it renders, so that even if the map is not fully rendered, the user can click links or the part of the map that is rendered.
Is there an easy way to do this? AJAX is one option, but since it is a Django website and the map depends on data from the Django template, AJAX becomes a bit unwieldy.
So is there a way to make the page visible while rendering?
(I considered making each node an iframe, so that they would be rendered individually, but that seems a bit silly too)
the django template should only render an empty map (or a map holding the first 10 points) with the javascript code firing on page ready
this javascript script should do this:
request 10 nodes from django (using a different url/view)
render the fetched nodes into the page
if no more nodes: END
goto 1.
Hope this helps
After trying a few different things, it seems that the problem was too many database queries. Each of the nodes made calls to the database while rendering, which caused them to be very slow.
For reference:
Custom filters in Django should not make database queries, if they are used heavily on a page
Based on the docs, I'm able to rearrange child views A,B,C of a container view to C,A,B by doing a "removeObject(A/B/C)" followed by a "pushObject(C/A/B)". For larger sets (my actual example is currently 64), is there a possibly more efficient way (such as say, just modifying a couple of values in the existing child views array? Although the remove/pushObject is probably just fine, given the relatively larger time for the actual UI re-render.
Thanks so much.
If you were using an ArrayController in combination with a CollectionView, you could use SortableMixin support to order its content according to your needs. Then your collection rendering would be updated as needed without any intervention on your side.
You could, for example, bind the sortProperties property of you controller to reflect the sorting criteria to apply.
(If you need further explanation, some code extract from your app will be welcome)
So I have been looking around for a couple hours for a solid solution to handling site navigation in CakePHP. Over the course of a dozen projects, I have rigged together something that works for each one, but what I'm looking for is ideally a CakePHP plugin that handles the following:
Navigation Model
Component for handing off to the view
Element View Helper for displaying the navigation (with control over sublevels displayed and automatically determining the "active" item based on URL and/or controller/model/slug
Admin pages for managing a tree of navigation
Any suggestions for an all-in-one solution or even the individual components would be very appreciated! Or even suggestions on how you have handled it in the past
We had this issue at work recently and i ended up whiping up a helper that would take query from the contents table and convert that into a menu. As it needed to become more flexible the code got worse and worse up to the point where i am currently rewriting it.
Don't hold your breath though as i will be taking my time to make it work right as it needs to be very flexible but it cant be confusing to use.