I'm working with a fairly generic, re-usable embeddable schema.
I'm stuck on a name for this "basic" schema!
"Basic"
Embeddable schema fields:
Banner (or large) Image as a multimedia link
Thumbnail Image (maybe, depends if large image is re-usable)
Headline (single-line text)
Summary (multi-line text)
Body Content (another embeddable schema, allow repeating)
Body Content
This should be familiar:
Body Subheader (single-line text)
Body Content (mandatory, allow repeating)
Would a name something related to the organization be appropriate for the "basic" embeddable schema? Maybe this should this either be broken out further or not even combined.
I suggest ARTICLE because HTML5 also use same name for such information and ARTICLE comes in HTML5 from recommendation of web developers across the globe.
How's about
General
Or
General Content
Difficult to say which one is better. I think all the answers so far are valid. I would probably go with Generic Paragraph only because you are in fact defining some kind of body of content (like a paragraph).
Also Generic Content or Generic are suitable names.
I feel it should be named as Generic?
One more thing:-
The fields which are mentioned, they might be used directly or indirectly by either one or more schemas based on requirements.
Headline + Summary + Body I normally call an Article, but your Generic is equally valid. The Banner + Thumbnail make it a bit more specific, so might make the name less correct - although the schema may be equally valid, depending on your use-case.
Related
Last month I read about Headless CMS for the first time, and I just felt in loved with that approach.
But just right after, I wondered how could I format and/or add style to the content if some day I worked with this technology.
By styling the content, I mean words within a title, paragraph and so on; not a whole paragraph, which is quite obvious it can be done.
It seems to me that it is impossible, since you only get a JSON with no HTML whatsoever; just raw texts. So it looks like this is the major downside of consuming content through a Headless CMS from a Front End perspective.
Formatting text is just fundamental, specially when dealing with large content. And I am sure I cannot be the first one concerned about not being able to add some bold and/or italics to a text to emphasize the important parts of it.
But I can't find any website discussing this topic, just "how to model the content" and whatnot.
Does really no one care about it?
I would appreciate if anyone could shed some light about this question.
Diving into the Headless CMS #RicoHancock has pointed out, I've learnt that it is completely feasible to store rich text and strucuted content within a JSON that can be converted to HTML following some specifications I wasn't aware of.
In the particular case of DatoCMS, they use a specification called dast.
To learn more about it, visit their docs (the following link contains very illustrative code examples):
https://www.datocms.com/docs/structured-text/dast
Paraphrasing their own words:
Structured Text format adheres to the Unified collective, which offers a big ecosystem of utilities to parse, transform, manipulate, convert and serialize content of any kind.
The "Unified collective" is a collective of free and open source packages to work with content as structured data with plugins. In order to create the syntax trees, Unified uses UNIST nodes.
UNIST is a specification, and stands for "UNiversal Syntax Tree".
More info about the UNIST spec and the Unified ecosystem:
https://github.com/syntax-tree/unist
https://unifiedjs.com/learn/guide/introduction-to-unified/
https://unifiedjs.com/learn/guide/using-unified/
TLDR: Markdown.
The company I work for uses DatoCMS. We have a blog, and each blog post is created in our CMS by our copywriting team. DatoCMS allows us (the developers) to create "blocks" that make up the blog post. We have image blocks and content blocks that are rendered by a template file on our frontend. The content blocks support Markdown, so italics, bold, and links work. When our copywriting/marketing team want to make a new blog post, they go to the CMS, create a new post, add a title, slug, and blocks, and then save.
I don't have much experience with other Headless CMS', so not sure if Markdown will work there, but I don't know why it wouldn't, Markdown is all over the internet. (In fact, this answer is Markdown XD)
I am aware than in many cases an HTML element does more than simple affect the page semantically, and the additional functionality make it a no-brainer choice. For example, although there is a textbox ARIA role, it is nearly always preferable to just use an <input> or <textarea> element whenever possible.
However, for "semantic" HTML elements, I can't find any information indicating that they do anything more than supply a default ARIA role for the purpose of accessibility and provide some minor code readability enhancements. For example, the only purpose of the <main> element (as far as I can tell) seems to be a "shortcut" to avoid typing out a few extra characters <div role="main">, also resulting in a slight readability improvement.
So, is that tiny readability improvement really the only reason to use <main> over <div role="main">, or are there other reasons I might be missing? Is there any conceivable reason that I would ever want to prefer the latter?
Semantically structuring your page with semantic HTML makes the contents machine-readable for the browser, browser extensions, search engines and other tools without extending their code to cover ARIA as well.
This is especially important for accessibility, as assistive technology are such tools, which might attach additional functionality to certain roles.
The browser’s read mode, for example, can easily extract contents from a <main>. Also handling role attributes makes coding it more difficult.
Also writing user stylesheets to improve accessibility is way easier if you don’t need to cover ARIA attributes.
W3C has written a complete doc about using aria : Using ARIA by W3C
The first rule of ARIA explains that you prioritize the native HTML element or attribute with the semantics and behavior already built in.
In your example, the element is a native HTML element with an implicit main role. You can give a look to the complete list of implicit roles of HTML.
I am a user, not a programmer, whose forthcoming new website on Plone 4 requires adding hyperlinks inside the Description field of pages and folders. This is needed to point specific words to our website Dictionary as we had been doing on EZ Publish for the last 10 years.
Our developer says this can't be done in Plone. I'm looking to help them find how to do this (they don't seem to use English-language forums).
Is there an existing add-on or existing code for this? If not, is it possible to code this in? How? If not, will it become standard in Plone 5?
<a href="http://python.org>Python</a> will not work, as the description-field is ment and used as a meta-information of an item, holding plain-text only, and doesn't allow the usage of html-elements, nor embedded Javascript. That's probably why T. K. Nguyen recommends to provide an additional rich-text-field.
But you can use reStrucuredText instead. Tell your developer to exchange the description-snippet in concerned templates to:
<div tal:define="Std modules/Products.PythonScripts/standard;
restructured_text nocall: Std/restructured_text;"
tal:content="structure python: restructured_text(context.Description())">
</div>
It will transform any word starting with 'http:' or 'https:' to a link, furthermore will also recognize mail-addresses like 'someone#plone.org' and transform them to mail-links (on click opens the user's default mail-client, if available, with the address pre-populated in the 'To'-field).
If you want to have named links, use the reStrucutredText-syntax for the input, like this:
`Check out Python`_, you'll love it.
`Write a mail`_ to someone.
.. _Python: http://www.python.org
.. _Write a mail: someone#example.org
The tricky part is to figure out, which templates are affected, but it's doable of my experience (did it with preserving line-breaks in listing-views, not reStructuredText).
Alternatively use a JS-workaround, as proposed by T. K. Nguyen. Be aware though, that it may break accessibility to some users.
It is possible to customize the description fields to be rich text (HTML) instead of plain text, but it requires a developer.
You can also use JavaScript to look at a description field and replace (for example) any string that starts with "http" with a hyperlink pointing to that URL. Your developer would have to look for examples of such JavaScript code and then would have to know how to register it on your site and then invoke it.
This describes how to do something similar, for PloneFormGen field help text (which is also plain text):
https://designinterventionsystems.com/blog/how-to-make-urls-clickable-in-ploneformgen-field-help-text
It might be easier to have your developer create a new rich-text description field and have all your content types include that new field. That, however, would require that you update the view templates for those modified content types. This is much easier with Dexterity, which ships with Plone 5 and is available for use with Plone 4.x.
imho it's a really bad idea to convert the description field to any richttext (html, rst, md) field. You need to change a hole bunch of templates to avoid html code rendered everywhere.
Example:
search
collections
content
portlets
Addons
The description is also often used as title attribute on links, in those cases you need to convert it to plain/text. And there are several more issues, where you could ran into.
As #T. Kim Nguyen wrote: Consider add a new textfield and show it, where necessary, probably implemented as a Viewlet in the below title slot.
Looking at your current site, it seems like you want this to provide a teaser for each article, which may contain links. If that is the case, then you can find other ways to do this without making the description html.
For instance, if you used collective.cover for your portal/collection pages then a Rich Text Tile would allow you to cut down the the object text to an appropriate size, but still edit it with a Rich Text editor, and keep/insert hyperlinks.
How to give option to add css
classes/IDs to content to in CMS's
content WYSIWYG builder/editor to non-
technical client who doesn't know
html, css but knows MS Word.
some time to make content according to design XHTML tags not enough. use of css classes needed.
Should we give only css .classes to
user or #Id can be given also?
and how we should write classes name
for ease of client?
In semantic way or like border4px, light-text and pretty-background ? Which method will be good for non-technical client to choose and remember appropriate classes?
How popular CMS given this option to
client ? What is best method
according usability?
Most Rich HTML online editors bring a "styles" drop down that allows the user to pick styles. See e.g. here for how it's solved in FCKEditor.
As for what styles to put in there, that depends totally on your client IMO. If they have design guidelines, you will want to put styles there that match the corporate font / colouring / design. You could also make this customizable by the user, there are several online CSS Editors around - they're not really for non-technical people, though.
As for whether to use IDs or classes: Absolutely and definitely classes. It's hard to prevent IDs from being assigned multiple times in a WYSIWYG editor, which is a total no-no.
The naming of classes is up to you, really. I like human-readable formats that at the same time are a class name:
HeadingBig
HeadingMedium
HeadingSmall
ProductCategory
ProductDeclaration
Quote
TipOfTheDay
those class names are obviously displayed to the user when selecting the class, so there is no need to keep separate, human-readable class names.
I'm implementing "news" section in asp.net website. There is a list of short versions of articles on one page and when you click one of the links it redirects you to a page with a full article. The problem is that the article's text on the second page will come from database but the articles may vary - some may have links, some may have an image or a set of images, may be differently formatted etc. The obvious solution that my friend have come up with is to keep the article in the database as html including all links, images, formatting, etc. Then it would be simply displayed on the second page. I feel this is not a good solution as if, for example, we decide to change the css class of some div inside this html (let's say it is used in all articles), we will have to find it and change in every single record of the articles table in our database. But on the other hand we have no idea how to do it differently. My question is: how do you usually handle something like this?
I personally don't like the idea of storing full html in the database. Here's an attempt at solving the problem.
Don't go for a potentially infinite number of layouts. Yes all articles may be different but if you stick to a few good layouts then you're going to save yourself a lot of hassle. These layouts can be stored as templates e.g ArticleWithImagesAtTheBottom, ArticleWithImagesOnLeft etc
This way, your headache is less as you can easily change the templates. I guess you could also argue then that the site has some consistency in layout.
Then for storage you have at least 2 options:
Use the model-per-view approach and have eg ArticleWithImagesAtTheBottomModel which would have properties like 1stparagraph, 2ndparagraph, MainImage, ExtraImages
Parse the article according to the template you want to use. e.g look for a paragraph break if you need to.
Always keep the images separate and reference them in another column/table in the db. That gives you most freedom.
By the way, option #2 would be slower as you'd have to parse on the fly each time. I like the model-per-view approach.
Essentially I guess I'm trying to say beware of making things to complicated. An infinite number of layout means an infinite number of potential problems. You can always add more templates as you go if you really want to expand, but you're probably best off starting with say 3 or 4 layouts.
EDITED FROM THIS POINT:
Actually, thinking about it this may not be the best solution. It could work depending on your needs, but I was wondering how the big sites do it. If you really need that much flexibility, you could (as I think was sort of suggested) use a custom markup. Maybe even a simplified or full wiki markup. I'd still tend toward using templates in general, but if you need to insert at least links and images then you can parse for those.
Surely the point of storing HTML with logically placed < div >s is that you DON'T have to go through every bit of HTML you store to make changes to styles?
I presume you're not using inline styles in your stored HTML, and are referencing an external CSS file, right?
The objection you raise to your colleague's proposal does not say anything about the use of a DB. A DB as opposed to what: files? Then it's all the same. You want to screw around with the HTML, you have to do it on "every single record." Which is not any harder than "on every single file." Global changes are a bitch unless you plan for it by, say, referencing an external CSS. But if you're going to have millions of news articles, you had better plan on versioning the CSS as well.
Anyway, the CMSes do what you're thinking of doing. Using a DB is a fine way to go. How to use it would depend on knowing the problem more intimately.
Have you looked into using free content management systems? I can think of a few good ones:
Joomla
Drupal
WordPress
TONS of others... just do some googling.
Check out this Wiki article: http://en.wikipedia.org/wiki/List_of_content_management_systems