Is there hierarchical taxonomy support in Umbraco 8? - taxonomy

we are considering to use Umbraco 8 as CMS system for displaying a number of items.
Those items must be tagged with tags from multiple hierarchies.
For example:
ITEM: horse, tags: livingbeing/animal/mammal, word/english/noun
Is this possible with Umbraco 8?

Not out of the box, I'd say. Umbraco has a Tags datatype within which I guess you could name the tags whatever you want, including / and whatever. But they would still just be a simple list of tags.
Also, the built in Tags datatype allows editors to create whatever new tags they want, there isn't an option to restrict editors to choose from a defined set of tags.
One common solution to this is to create simple content nodes (in a hierarchy if you want) and use them as "tags" instead. Then you can fairly easily create a tag picker with which you are only allowed to select existing nodes/tags.

Related

Is it possible to classify RTD pages using tags (sort of taxonomy)?

I would like to add for every page a sort of classification using comma separated tags (i.e. javascript, REST, HTML5).
And I would like to have a way to use one of this tag, to open the list of the pages classified using this tag.
Is it possible?

Semantics of class vs ID in reusable templates

I'm working on an online store. I've learned a little PHP and so I'm using a single template file with some conditional includes and such rather than building separate product pages (no database yet though, still learning!).
So I have sections that only exist once per instance of the template (ie once per page) such as section id="product_image". Normally that would be identified with an id. But on a template which is reused a bunch of times do you think class would be more semantically appropriate? (yes I know there's no functional/technical need to switch to class)
An id is singular. There can be only one of the same ID on the page, and an element may only have one ID attribute.
So if your component gets reused, the ID must be different between reuses (Perhaps some sort of database primary key, or something similar).
A class name describes your elements semantically, i.e. this section is a what? widget? calendar? featured articles? That's what a class name is for.
Personally, I always use class names, and only use IDs if I want the link-scroll functionality. Classes, are everything IDs are, but more flexible.
the id and class attributes may be used for structure and functionality, but not semantic meaning, although readability in markup is a great aim.
To infuse your markup with meaning, use semantic elements, and structured data.
The Google Structured Data Testing Tool is a great resource.

Adding microdata to Concrete5 through a content editor

TinyMCE strips certain microdata from content entries when added to the html. I'm building a website for a mobile spa service, and would like to list their services as products using schema.org's markup. So my question is this: Is there a wysiwyg editor block I can let my client use that wont "clean" microdata I end up putting in later?
This may not be a direct answer to your question, but depending on how structured the content is, you might consider creating a new block type using Designer Content and then wrap individual fields with microdata tags.
http://www.concrete5.org/marketplace/addons/designer-content/

Extract content from a page

I need to recognize content in a page - to do something as so http://www.alchemyapi.com/api/text/ (I need to get the HTML so I cant use this API)
What logic can I use to accomplish this? (Coding language is not matter)
Here what I did (with a good result) - needs a lot more fixes...
Find the most text in page so don't have a breaking tags - ignore inline tags (span, b, etc...)
Go up one level and count breaking tags (br, p, div, etc...)
Go up another level and count tags
Compare tags count from step 2 with step 3
If there is a lot of different we stop here - if not we go to step 3
Look for the Boilerpipe library. It is a comprehensive solution.
Using the Boilerpipe library, you can specify the output as HTML. So you get the main content(the article) while still preserving its HTML tags.
Another good alternative would be to use Goose.
It allows more fields(published date, author, main image in article and a few more) than Boilerpipe (title, content)
You need a parser for navigate the DOM, in the NuGet packages you can find some helpful parser tools like this

Adding ids to HTML tags for QA automation

I have a query In our application we have lots of HTML tags. During development many tags were not given any id because of no requirement.Now the QA team wants to automate the test cases using QTP. In most of the cases this tool doesn't recognizes because it does not find ids for most of the HTML tags.Now we are asked to add ids to all the HTML tags.
I want to know if there will be any effect adding id attribute to these tags. Even positive impact are welcome
I do not think there will be any either positive or negative effect : maybe the size of the HTML page will increase a bit, but probably not that much.
Still, are you sure you need to put "id" attributes on every HTML tag of your pages ? Wouldn't only a few of those be enough ? Like on form fields, on links, on error-messages ; and that's probably about it ?
One thing you must take care, though, is that "id", as in "identifers", must be unique ; which implies it might be good, before starting adding them, to define some kind of "id-policy", to say, for instance, that "ids for elements of that kind should be named that way".
And, for your next projects : have developpers add those when theyr're developping ;-)
(And following the policy, of course)
Now that I'm thinking about it : a positive effect might be that it'll be easier to write Javascript code interacting with your HTML document -- but that'll be true for next projects or evolutions for this one, when those id are already present in the HTML at the time developpers put the JS code in place...
Since there are no QTP related answers yet.
GUI recognition in QTP is object-oriented. In order to identify an object QTP needs a unique combination of object's properties, and checking them better to be as fast as possible - that is why HTML ID would be ideal.
Now, where it is especially critical - for objects that do not have other unique identifiers. The most typical example - html tables. Their contents is dynamic, their number on the page may vary. By adding HTML ID you allow recognition mechanism get straight to the right table.
Objects with other unique properties can be recognized well without HTML ID. For example, if you have a single "submit" link on the page QTP will successfully recognize it by inner text.
So the context-specific answer: don't start adding ids to every single tag. Ask automation guys to prepare a list of objects they have problem with. And add ids to those objects.
PS. It also depends on automation programming skills. There are descriptive programming and dynamic recognition methods. They allow retrieving the right objects even without ids provided.
As Albert said, QTP doesn't rely solely on elements' id, in fact due to the fact that many web applications generate different ids for each session, (as far as I remember) the id property isn't part of the default description for most web test objects.
QTP is pretty good at recognizing most simple web controls and if you're facing problems it may be the case that a Web Extensibility project will help you bridge the gap between the semantics of your web application and the raw HTML it is created in. If a complex control is recognized by QTP as a WebElement (which is actually the div that contains the span that drives the code) you will understandably have object recognition problems since there are many divs on the page but probably many less complex controls.
If you are talking about side-effects - NO. Adding ids won't cause any problems (apart from taking up some extra bytes of course)
If you really have the need to add ids, go ahead and add them.
http://www.w3.org/TR/html4/struct/links.html#anchors-with-id says: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical.