create api endpoint to serve partials about resource-rest-bundle HOT 19 CLOSED

I would propose to devide templates by application and an identifiert and define a configuration like that:

bundle:
   partials:
     frontend-editing:
         edit: MyBundle:From:edit.html.twig
    admin-panel:
         edit: MyAdminBundle:From:edit.html.twig
         delete: MyAdminBundle:From:delete.html.twig
         list: MyAdminBundle:From:list.html.twig

from resource-rest-bundle.

As far as I can understand this issue, it has nothing to do with resource finding (puli's only task) or presenting found resources (ResourceRestBundle's only task). If you want something like this, you need a custom bundle/api imo

from resource-rest-bundle.

But we are serving resources in that bundle, right? Atm we are serving resource from two repos (phpcr, repo), so why not serving resources like pre-rendered html scripts, filled with values from phpcr?

from resource-rest-bundle.

@wouterj but you are right, that can be in an own symfony wide bundle, too.

from resource-rest-bundle.

This bundle (ResourceBundle actually) can easily be extended to read from custom repositories, so you can create a bundle that adds a resource repository for HTML templates.

from resource-rest-bundle.

i think this discussion got a bit mixed up. @ElectricMaxxx you are thinking not about providing html templates, but about applying such templates to documents to render them server side, e.g. render a form or render a block, right?

so instead of an endpoint providing document transformed to json, it would serve a rendered form or something for that document. i feel that this should be a separate bundle, as its much more specific than transforming to json. its a bit like the ImagineBundle that can apply some filter to an image, we apply a template to a document. but you might also need a custom service for some tasks on some document types because its more complicated than rendering a class in twig. e.g. creating a form with that document. not all documents make sense with all filters, so we get into an interesting conflict between tree based and document type based logic.

have you looked at the SonataBlockBundle? i think there is some overlap with what it wants to achieve (but the block bundle is limited to some use cases, and some of its architecture is not ideal). if this thing we are talking here works well, it might replace the block bundle with a more generic solution.

from resource-rest-bundle.

Yea ...

So you all wouls suggest to put that stuff into an own Bundle, so i will do it.

A question would be to put that into the symfony-cmf organisation as it is responsible to serve serverside stuff, or but into the new angular-cmf organisations as its modules would need or consume that stuff.

@dbu i wouldn't need form only. Even the smal snippet of a single item in a custom listview (for instance a newspaper wants to show articles in its frontend) woult be a partial. In JS-Framworks you are working with smaller templates than you do on serverside applications. Even a Button can have its own little view. In that case it would be nice to have one endpoint to get every little parital/view once and passing them as strings into the application (easy in angular or even backbone). The only problem are the delimiters, as Twig uses {{ }} and angular too a need to change them in angular into {[ ]}
I would need the rendered views in so called providers in angular. That are html constructs, where you are can pass vallues into an encapsulated blok/widged`. Example:

<cmf-doc-list items="[{% for item in items %} // render doc into a nice way {% endfor %}]" attr-one="{{value-one}}">
</cmf-doc-list>

Now i would be able to write a so called Provider which is able to consume the passed values and render a custom template into (instead) that new html element. This would be a good way beside GET /api/v1/repo_phpcr/( REST call to get them all), to have the documents inside of the application - not really inside as the provider work in a very encapsulated way, but we want them to do so.
The reason why i want the partials to come from the cmf application is to give the developer a chance to customize the templates in a way i used to do it before.

from resource-rest-bundle.

are we talking about serving angular templates that are rendered in javascript to a frontend? or about rendered content? if its the first, does the ResourceRestBundle need to semantically understand what it is doing?

regarding storing templates in the repository: since working with drupal 6, i have the horror of mixing application logic into a database (deployments of new features just get horribly complicated, a setup with testing and production environment gets a lot harder and at least in my experience the application users don't ever actually change anything or if they try to, they break stuff). this is just my opinion, and some big "enterprise" cms boast about having everything in the db (including css and whatnot) so it seems to be a thing. but i would suggest keeping the two things separate:

1. something that serves snippets. the snippets could be fetched through puli - if i got it right it would be possible to "mount" phpcr paths into a puli tree
2. something that allows to edit snippets and store them in phpcr.

from resource-rest-bundle.

Please note that, if we move to full Puli, we won't be talking to the PHPCR repository directly anymore, but just to Puli. This means that Puli can abstract where it's coming from.

For instance: $repo->get('/templates/part/sidebar'); might live in app/Resources/views/part/sidebar, while $repo->get('/routes/home'); lives in PHPCR.

from resource-rest-bundle.

👍 for the snippets, yes that wohl the main responsibility. Those templates would live Inside the own application or a CMF bundle. The user of the CMF will be able to manipulate it the symfony way and the PartialsBundle would serve them in a getOne/getAll route.

👎 for the persisting of rendered templates, cause we need to take care on them when the underling data was changed. So i would flag them as toBeRendered, fetch the data and serve them. The cache can handle the die overhead, isn't it? (The World would look different, if we would provide a solution for fast read requests on preRendered html persisted in a redis for the CMF in generall. Then i would prefere that)

from resource-rest-bundle.

from resource-rest-bundle.

@ElectricMaxxx I think it already is implemented. What you need is mounting the filesystem repository in the ResourceBundle config and you're ready.

For instance:

cmf_resource:
    repositories:
        snippets:
            type: filesystem
            base_dir: "%kernel.root_dir%/Resources/snippets"

        default:
            type: composite
            mounts:
                - { repository: snippets, mountpoint: /snippets }

Now you can access app/Resources/snippets/sidebar.html by requesting /api/default/snippets/sidebar.html.

from resource-rest-bundle.

@ElectricMaxxx i am still a bit confused: do you need a source for templates that angular is rendering in the browser, or also want the backend to deliver rendered output that can just be displayed by angular?

from resource-rest-bundle.

from resource-rest-bundle.

i would try to separate the things, because they are quite different. the ResourceRestBundle can easily deliver resources like a template "file" coming from wherever thanks to puli. but to render, you have this multiple relation between document and template, and need either logic in the frontend to tell which template to use or have that logic in the backend to find the right template for the right situation. that combine-logic seems like a separate bundle to me.

btw, what is the templating language? there is a nice handlebars bundle to render handlebars in php. if you want the same templates on backend and frontend, that could be useful.

from resource-rest-bundle.

I think there should be no preselection for the template engine. It should be no problem to have an Application/Bundle on CMF server side which provides snippets for an Angular-CMF application, means the angular template, means html. Switching to an other template engine would just be an overwrite of the given templates by mustache for example. The only problem will be the delimiters. Angular and Twig are both using {{ }}, so i would change the delimiters in the angular application.
But to answer your question: yea my use case is (angular) html.

from resource-rest-bundle.

from resource-rest-bundle.

Closing as this bundle is now able to provide file contents through the API.

from resource-rest-bundle.

from resource-rest-bundle.