Template Engine about web-publisher HOT 17 CLOSED

what about configuring it using xml config file and not annotations (I mean Context annotations here)? I think we will be able to reuse the context object classes without relying on the coupled annotations since we will have it in a separate files (not in the classes itself) thus the classes will be independent. In my opinion, in this case abstracting it away from the code would make sense, what do you think about it ?

from web-publisher.

what would be pluses of using context config in seperate xml files? We should be able reuse context object anywhere, annotations are just one way to automatically fill context with needed objects. You will can still use methods like that:

$context->set('article', $article);

from web-publisher.

Fetching data from the context in Twig template

{{ g.get('articles', {param:1})) }}

• function above will fetch articles by given parameters
• articles can be replaced by a different value, e.g. authors - authors will be fetched by given parameters instead.

Pros:

• one function to maintain (no need to create methods like getArticles, getAuthors etc.) - documenting ease.

Cons:

• ?

from web-publisher.

not sure if those Meta classes should have methods, imo it would be better to keep there only data and provide template blocks/functions. so there would be g.article.images list and block:

{{ image src=g.article.images.0 width=300 height=200 }}
<img {{ g.image.params }}>
{{ /image }}

otherwise it's kind of complicated to use that - you have to store the func result somewhere and check it returned something etc.

from web-publisher.

also not sure about this change method, imo it would be better to use blocks again:

{{ article slugline="something" }} here you have the article context {{ /article }} and you're back where you were

this way you can in theory cache that block based on article updated time and in case you can't find it you just don't display it so it's more like component

if article change doesn't work there is no way to continue rendering after..

from web-publisher.

Get single object:

{% get ‘article’ {param: 1}  %}
     {{ article.name }} 
{% endget %}

Get many objects:

{% list ‘articles’ {param: 1} limit=10  %}
     {{ article.name }} 
     {% render_pagination %}
{% endlist %}

from web-publisher.

ok, so to do not forget - i will add this in comment and then update proposal.

Rafał comment (#13 (comment)) is our proposal for template side - fetching single item (different that one in context) and creating loops through collection of objects.

We also decided to keep template "meta" objects configuration in yaml format seperate to entities. This same with phpcr configuration for documents.

Objects exposed for templators will be type of SWP/TemplateEngine/Meta and will be simple object with __get magic methods witch will expose only defined in configuration properties from storage objects (documents).

from web-publisher.

looks good. not sure about this meta class thing with magic methods, i would rather keep it simple, more like in newscoop but as long as it's simple to create those meta classes without having an entity it should be fine. concerns for usage of those are - simple json dumping for javascript and using this in unittests.
so can you json_encode() metaclass?

from web-publisher.

We should be able to json_encode metaclass. And this metaclass will can be filled with any data, by default automatically it will look for public properties and getters in provided object, but still we should be abble to fill it in other ways.

from web-publisher.

should be fine then

from web-publisher.

Hm... it reads like PHP 1.0 :) meaning: is this a template language for front end designers or is this a programming language?

from web-publisher.

Template section is for templators, rest is for developers, and it's realy close to that what we have in Newscoop templates (blocks, and lists).

from web-publisher.

Hi guys, just want to suggest a few things in general, not sure about the specifics. My brain isn't good enough for this. But what do you think about this:

1. wording of variables should be the same as in the Superdesk Content API. If it is called "item" in Superdesk, it should not be called "article" in the web publishing template. This I say from experience. Horrible experience. Painful. You don't want that. Please check in with the Content API guys.
2. there should be one way of doing something, not many. As much as I like Larry Wall's post modern take on programming ( http://crossfade.walkerart.org/radioqualia/index.html ), if you use gimme, use it everywhere. If you use g. use it everywhere. Do not use both.
3. before anything goes into commits, check the name spaces / variable wording with at least one native speaker and at least one newsroom magician. In this case, the language is a tool and means something. We can not accept inaccuracy and sloppy wording.

from web-publisher.

Hey @MiczFlor,

1. Main question if people working with templates will need to know that behind web publisher is Superdesk Content API, and if inside Superdesk Web Publisher they will still work with items or maybe with final web product - articles/pages ? Content API naming is designed for developer who will build app on this - not exactly some frontend guy who knows some jQuery and html and have contact do designer.
2. There will be one naming - probably gimme ;)
3. We will need find newsroom magician, and include him in our pull requests review workflow.

from web-publisher.

Currently in lists we have: length, ordering, ignoring context levels, constraints. Having less than this wouldn't be good.
How this listing will look like in Web publisher? For example some article list rich with options currently looks like this
{{ list_articles length="10" columns="5" ignore_issue="true" ignore_section="true" order="byPopularity desc" constraints="type is news author is $escapedAuthor publish_date greater $threeDaysAgo" }}
how it translates to new system?

from web-publisher.

{% gimmelist article in articles|length(10)|order('popularity, 'desc') with {
    type: 'news',
    autor: escapedAuthor, 
    publish_date: '>= '~threeDaysAgo
} %}

from web-publisher.

collumns and ignoring context stuff - not sure if we will have features like that

from web-publisher.