prismic.io

[Lukas Kahwe Smith]

Aloha,

I have mentioned this on twitter before as a crazy idea, but the more I think about it the more I think this could be huge:
Lets make a PHPCR implementation for https://prismic.io

I think a read only implementation really should only take a few days and would give us several benefits:
- a huge marketing splash (I am hopeful that prismic.io would be excited too)
- solid media asset management
- a nice admin UI with versioning and content staging etc
- helping people to understand the decoupled nature of the CMF

Support for their query language should also be possible. Write support will be a bit more work but it is certainly doable. But these are things we can do once we have proven that it works to build and maintain a website.

Who is in?

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Lukas Kahwe Smith]

BTW for those unaware, we already have a precedent for integrating a data source for PHPCR via HTTP: Jackrabbit.
Also with the way Jackalope is built, all the basic infrastructure for PHPCR can be reused and only a few methods need to be implemented for read support:
https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/TransportInterface.php

[Ben Glassman]

I'd be interested

[Rudy Rigot]

Hey guys, I'm Rudy and I work for prismic.io.

I know little about PHPCR, but I've started reading about it, and I feel this could be really fun!!

Do note that we don't have a write API yet, it's all about retrieving for now, so I'm not positive all of your idea is achievable today, but I'll do my utmost to help you go as far as you think is possible with it.

Let me know what you need, and I'll make it happen. :)

-- Rudy.

[David Buchmann]

hi rudy,

great to hear that prismic wants to support this. watch out, we might
come back on that ;-)

phpcr is a set of interfaces to work with hierarchical data on a low
level. there is phpcr-odm that can map the raw nodes to domain specific
objects, which is a member of the doctrine family.

we have the whole engine working with the content repository server
jackrabbit, and a simple implementation on top of relational databases.
the actual storage is separated, so all that should be needed is
implementing one interface to read data and provide the right format:
https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/TransportInterface.php

the specification actually contains capability checks so that
implementations can announce what they support. read only is the minimum
spec, so that would do fine.

i guess at this point we just hope for somebody to pick up the ball and
try to implement this interface with the prismic.io protocol. is there a
php client to talk the http protocol with prisimic.io? otherwise i guess
we can use guzzle or something like that and the people who dig into
this might come to you with questions about the http protocol if needed.

cheers,david

On 16.04.2014 20:23, Rudy Rigot wrote:
> Hey guys, I'm Rudy and I work for prismic.io.
>
> I know little about PHPCR, but I've started reading about it, and I feel
> this could be really fun!!
> Do note that we don't have a write API yet, it's all about retrieving
> for now, so I'm not positive all of your idea is achievable today, but
> I'll do my utmost to help you go as far as you think is possible with it.
>
> Let me know what you need, and I'll make it happen. :)
>
> -- Rudy.
>
>
> On Wednesday, April 16, 2014 6:33:32 AM UTC-7, Ben Glassman wrote:
>
> I'd be interested
>
>
> On Wed, Apr 16, 2014 at 4:14 AM, Lukas Kahwe Smith
> <sm...@pooteeweet.org <javascript:>> wrote:
>
>
> On 16 Apr 2014, at 10:06, Lukas Kahwe Smith

> <sm...@pooteeweet.org <javascript:>> wrote:
>
> > Aloha,
> >
> > I have mentioned this on twitter before as a crazy idea, but
> the more I think about it the more I think this could be huge:
> > Lets make a PHPCR implementation for https://prismic.io
> >
> > I think a read only implementation really should only take a
> few days and would give us several benefits:
> > - a huge marketing splash (I am hopeful that prismic.io

> <http://prismic.io> would be excited too)

> > - solid media asset management
> > - a nice admin UI with versioning and content staging etc
> > - helping people to understand the decoupled nature of the CMF
> >
> > Support for their query language should also be possible.
> Write support will be a bit more work but it is certainly
> doable. But these are things we can do once we have proven that
> it works to build and maintain a website.
> >
> > Who is in?
>
> BTW for those unaware, we already have a precedent for
> integrating a data source for PHPCR via HTTP: Jackrabbit.
> Also with the way Jackalope is built, all the basic
> infrastructure for PHPCR can be reused and only a few methods
> need to be implemented for read support:
> https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/TransportInterface.php
> <https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/TransportInterface.php>
>
> regards,
> Lukas Kahwe Smith

> sm...@pooteeweet.org <javascript:>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-de...@googlegroups.com
> <mailto:symfony-cmf-de...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch

[Rudy Rigot]

Hey,

This definitely sounds good!

If read-only suffices for a start, then it's all good; and we could go further once prismic.io's write API gets released (this is definitely something we do have in mind).

We do have a PHP kit which is right here: https://github.com/prismicio/php-kit

The basics of how our kits work are detailed in our cross-technology documentation here. Since it's cross-device, it isn't written with PHP's syntax in particular, but it gets the job done pretty well as of how the whole thing works on a high level.

I've been a maintainer on our kits, and on the PHP kit in particular as well, so feel free to ask me any question, I know it really really well. ;)

--

[Lukas Kahwe Smith]

On 17 Apr 2014, at 01:30, Rudy Rigot <rudy....@gmail.com> wrote:

> Hey,
>
> This definitely sounds good!
>
> If read-only suffices for a start, then it's all good; and we could go further once prismic.io's write API gets released (this is definitely something we do have in mind).
>
> We do have a PHP kit which is right here: https://github.com/prismicio/php-kit
> The basics of how our kits work are detailed in our cross-technology documentation here. Since it's cross-device, it isn't written with PHP's syntax in particular, but it gets the job done pretty well as of how the whole thing works on a high level.
> I've been a maintainer on our kits, and on the PHP kit in particular as well, so feel free to ask me any question, I know it really really well. ;)

Alright .. I have started hacking on this on the train. Which mostly means I am reading the docs, looking over the symfony starter example and forking the Doctrine DBAL PHPCR transport and renaming and stripping out stuff. Will likely create the new Prismicio transport repository tonight. I hope to have something that reads something early next week. Depends on how much quality time I get with a decent enough internet connection.

Then again maybe I can cook up something with https://github.com/php-vcr/php-vcr that would allow me to test things even without an internet connection.

[gmx Privat]

Hi Lukas,

Would like to see how you have done that. Maybe in a documentation like "create your own phpcr implementation" or i will have a look in your code. Cause i will try to write a own one for a client project, where i would need to fetch data from a cms called "alpCms". If i would get it to work with "just" a phpcr implementation would make lots of stuff much easier.

Mit freundlichen Grüßen

Maximilian Berghoff


---------------------------------------
Maximilian Berghoff
Wiesenstraße 44
91617 Oberdachstetten

Mail: Maximilia...@gmx.de
Mobile: +49 151 84625096

[Wouter de Jong]

Max,

Just create a new Jackalope Transport repository by implementing the interface in real implementation classes.

--
You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.

[Lukas Kahwe Smith]

On 17 Apr 2014, at 01:30, Rudy Rigot <rudy....@gmail.com> wrote:

> Hey,
>
> This definitely sounds good!
>
> If read-only suffices for a start, then it's all good; and we could go further once prismic.io's write API gets released (this is definitely something we do have in mind).
>
> We do have a PHP kit which is right here: https://github.com/prismicio/php-kit
> The basics of how our kits work are detailed in our cross-technology documentation here. Since it's cross-device, it isn't written with PHP's syntax in particular, but it gets the job done pretty well as of how the whole thing works on a high level.
> I've been a maintainer on our kits, and on the PHP kit in particular as well, so feel free to ask me any question, I know it really really well. ;)

Hi Rudy,

So I have been playing around with Prismic a bit and I have a few questions to figure out how to best map Prismic to PHPCR:

1) does Prismic have a concept similar to PHPCR workspaces. FYI PHPCR workspaces are in effect separate tree structures. I assume in Prismic these are separate endpoints? In that spirit, is it possible to generate a single access token to read from various endpoints?

2) is there a way to structure content (into a tree structure)? if so how? from now I only see how to access documents by id (which I guess is some sort of UUID equivalent?) what we need in PHPCR is some way to identify documents not only by UUID but also by path

[Lukas Kahwe Smith]

On 19 Apr 2014, at 23:23, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:

>
> On 17 Apr 2014, at 01:30, Rudy Rigot <rudy....@gmail.com> wrote:
>
>> Hey,
>>
>> This definitely sounds good!
>>
>> If read-only suffices for a start, then it's all good; and we could go further once prismic.io's write API gets released (this is definitely something we do have in mind).
>>
>> We do have a PHP kit which is right here: https://github.com/prismicio/php-kit
>> The basics of how our kits work are detailed in our cross-technology documentation here. Since it's cross-device, it isn't written with PHP's syntax in particular, but it gets the job done pretty well as of how the whole thing works on a high level.
>> I've been a maintainer on our kits, and on the PHP kit in particular as well, so feel free to ask me any question, I know it really really well. ;)
>
> Hi Rudy,
>
> So I have been playing around with Prismic a bit and I have a few questions to figure out how to best map Prismic to PHPCR:
>
> 1) does Prismic have a concept similar to PHPCR workspaces. FYI PHPCR workspaces are in effect separate tree structures. I assume in Prismic these are separate endpoints? In that spirit, is it possible to generate a single access token to read from various endpoints?

using https://%s.prismic.io/api as my “URL” parameter and replace “%s” with the workspace name ..

> 2) is there a way to structure content (into a tree structure)? if so how? from now I only see how to access documents by id (which I guess is some sort of UUID equivalent?) what we need in PHPCR is some way to identify documents not only by UUID but also by path

so I have a working versions .. though its just a proof of concept. for now I have a “virtual” root node (aka “/“) that is nt:unstructured and has children that have node names matching their Prismic document id (the node name is also used as their jcr:uuid). The children in turn currently just have a single property with their slug:
https://github.com/jackalope/jackalope-prismic/pull/1

Lots of TODO’s open but I can get the listing in the php-symfony-starter with the following code (https://github.com/lsmith77/PrismicBundle/pull/2):
diff --git a/Controller/DefaultController.php b/Controller/DefaultController.php
index b6f82ad..5e91300 100755
--- a/Controller/DefaultController.php
+++ b/Controller/DefaultController.php
@@ -20,7 +20,7 @@ class DefaultController extends Controller
public function indexAction()
{
$ctx = $this->get('prismic.context');
- $docs = $ctx->getApi()->forms()->everything->ref($ctx->getRef())->submit();
+ $docs = $this->get('doctrine_phpcr')->getConnection()->getRootNode();

return array(
'ctx' => $ctx,
diff --git a/Resources/views/Default/index.html.twig b/Resources/views/Default/index.html.twig
index 17d3f5e..bec5e0a 100755
--- a/Resources/views/Default/index.html.twig
+++ b/Resources/views/Default/index.html.twig
@@ -25,8 +25,8 @@
<ul>
{% for doc in docs %}
<li>
- <a href="{{ path('detail', {'id': doc.getId, 'slug': doc.slug, 'ref': ctx.maybeRef}) }}">
- {{ doc.slug }}
+ <a href="{{ path('detail', {'id': doc.getIdentifier(), 'slug': doc.getPropertyValue('slug'), 'ref': ctx.maybeRef}) }}">
+ {{ doc.getPropertyValue('slug') }}
</a>
</li>
{% endfor %}

[Rudy Rigot]

Hey,

Wow, you, sir, are some efficient dude!! ;)

Indeed, it seems like what you call workspaces is what prismic.io calls repositories, and I confirm each repository/workspace has one endpoint, and one access token. A given user account can access several repositories/workspaces with the same credentials (using OAuth2), but I confirm the access token will be different per repository anyway. If your content repository is public however, you don't need credentials, and can create access tokens on the fly; but no accessible document tells you which repository a user has credentials for, even if it's yourself.

I didn't realize PHPCR had a tree structure concept. We decided we'd try to stay away from organizing content in trees, because people tend to use them to organize stuff following their website's navigation, which is a very form-related way of doing things. We noticed the same content that is reused across applications rarely follows exactly the same tree organization (think: content that is organized on a website vs. content that is in a smartphone app, for instance).

So what we think is: if we give people the means to "qualify" their documents in ways that are powerful enough semantically, then they will naturally stay away from following their website's tree structure to organize their content in a content repository. There are three ways to qualify a document in prismic.io: if it's unique in the whole repository (like the terms of service, or the "about" document, etc.) then you can bookmark it with a unique name; if a set of documents is defined by the values of some of their fragments, then you should be allowed to use this as the qualification of a set of documents; and if you want to define a set of documents but no existing data keeps them together, then you should use our tagging system (you can tag documents across document types).

I'm new to PHPCR, so I'm not sure I'm using the right words, but I hope you get the idea. If I'm not very clear with it, let me know how I can clarify, I feel I can learn a lot from talking about those with you guys. :)

--

[Lukas Kahwe Smith]

On 20 Apr 2014, at 20:20, Rudy Rigot <rudy....@gmail.com> wrote:

> Hey,
>

> Wow, you, sir, are some efficient dude!! ;)
>
> Indeed, it seems like what you call workspaces is what prismic.io calls repositories, and I confirm each repository/workspace has one endpoint, and one access token. A given user account can access several repositories/workspaces with the same credentials (using OAuth2), but I confirm the access token will be different per repository anyway. If your content repository is public however, you don't need credentials, and can create access tokens on the fly; but no accessible document tells you which repository a user has credentials for, even if it's yourself.

ok .. sounds good.

> I didn't realize PHPCR had a tree structure concept. We decided we'd try to stay away from organizing content in trees, because people tend to use them to organize stuff following their website's navigation, which is a very form-related way of doing things. We noticed the same content that is reused across applications rarely follows exactly the same tree organization (think: content that is organized on a website vs. content that is in a smartphone app, for instance).

we agree here in the CMF .. for this reason we provide two approaches:
1) content structure matches website structure
2) website structure references content structure

Obviously one can have several different “website structures” for different devices/languages and whatever other dimensions.

> So what we think is: if we give people the means to "qualify" their documents in ways that are powerful enough semantically, then they will naturally stay away from following their website's tree structure to organize their content in a content repository. There are three ways to qualify a document in prismic.io: if it's unique in the whole repository (like the terms of service, or the "about" document, etc.) then you can bookmark it with a unique name; if a set of documents is defined by the values of some of their fragments, then you should be allowed to use this as the qualification of a set of documents; and if you want to define a set of documents but no existing data keeps them together, then you should use our tagging system (you can tag documents across document types).
>
> I'm new to PHPCR, so I'm not sure I'm using the right words, but I hope you get the idea. If I'm not very clear with it, let me know how I can clarify, I feel I can learn a lot from talking about those with you guys. :)

You have already picked up on the fact that PHPCR is based on the concepts of JCR so there is a lot of history in what we provide. I agree that tags etc are often a better way to structure your content “dynamically” but for any website that starts to manage 100+ content pieces, it becomes tricky to keep things flat and you want to delegate responsibility and there tree structures can be quite an effective solution. Also as noted above, you may want to have different “views” or “structures” for different output devices and languages. Here being able to reference content into other structures is useful. I guess for now we will just model a flat structure using bookmarks and see how that goes. Another option is of course to require a custom “path” property but if this isn’t a native concept in prismic.io, I expect that the content authoring experience will suffer.

[Rudy Rigot]

Ok, different content organizations for different applications, I understand the approach better. This is something we want to stay away from as much as possible, we believe that giving powerful enough ways to organize stuff semantically would allow a single content repository to serve virtually unlimited applications without ever increasing complexity in the content repository.

(It's a fun play on word, but what we call "content structure" is the structure inside the content, not the way to organize documents, so I had a hard time understanding your e-mail at first!) ;)

About languages, we're coming up with a feature that will be dedicated to internationalization. We've been receiving a lot of feedback from people who need to be doing internationalization efficiently. As I'm sure you figured out, it's entirely possible today to built internationalized content with prismic.io concepts (using documents links, and tags, for instance), our feature will mostly bring a better UI to get it done smoothly in the writing-room.

I confirm that using a "path" fragment (or better: using paths as tag names) are both workarounds, although they definitely may work technically. Your content writing experience wouldn't be so great though, and you'd need to make sure not to write typos (would be easier with tags, as they auto-complete, but still).

But your feedback about tree structures is really very interesting and insightful; I'll make sure to circle it back to the team. Thanks a lot for that!

-- Rudy.

[Lukas Kahwe Smith]

On 21 Apr 2014, at 19:14, Rudy Rigot <rudy....@gmail.com> wrote:

> Ok, different content organizations for different applications, I understand the approach better. This is something we want to stay away from as much as possible, we believe that giving powerful enough ways to organize stuff semantically would allow a single content repository to serve virtually unlimited applications without ever increasing complexity in the content repository.

sure .. semantic organization I would then however expect tags to allow for more structuring.
lets say I have a news magazine and I have a new article that covers how politics uses sports for their agenda.
I can obviously file that under the tags: “sports”, “politics”
The article will also have a date and an author etc.

Based on this information I could create a path on the website like:

/2014-04-22/sports/Ueaadawewwe/politics-in-sports.html

and also generate another such link under:

/2014-04-22/politics/Ueaadawewwe/politics-in-sports.html
though here I would want to have a canonical url pointing to the above link

so yeah its awesome that via tags and properties I can build virutal structures using the query API. but to be able to define the canonical URL I think using a property like “canonical tag” is iffy.

furthermore lets expand this further for multi lang, multi devices etc. I think an entirely search based virtual navigation and URL structure will quickly become very confusing to manage. essentially one will need to built a tool that sits between the website(s) and prismic.io to manage this tree structure. If you put sorting into the mix it gets even trickier, ie. what if you want your articles inside these categories to be sorted in a specific way? I guess with structured documents you can do that, but do I really want to open a document with for the category to embed a sorted list of reference documents? again it seems from a UI perspective for that use case a tree structure is much easier and efficient to deal with.

I do acknowledge that this issue only starts to happen when you have enough content and enough different site representing that content that this might be necessary and maybe the main target audience you are addressing (for now) simply does not have that problem. But if you do go in that space, I think you will need something there.

> (It's a fun play on word, but what we call "content structure" is the structure inside the content, not the way to organize documents, so I had a hard time understanding your e-mail at first!) ;)
>
> About languages, we're coming up with a feature that will be dedicated to internationalization. We've been receiving a lot of feedback from people who need to be doing internationalization efficiently. As I'm sure you figured out, it's entirely possible today to built internationalized content with prismic.io concepts (using documents links, and tags, for instance), our feature will mostly bring a better UI to get it done smoothly in the writing-room.

nice!

> I confirm that using a "path" fragment (or better: using paths as tag names) are both workarounds, although they definitely may work technically. Your content writing experience wouldn't be so great though, and you'd need to make sure not to write typos (would be easier with tags, as they auto-complete, but still).
>
> But your feedback about tree structures is really very interesting and insightful; I'll make sure to circle it back to the team. Thanks a lot for that!

cool .. I think managing this tree structure is likely something that content admins do not need, but publishers will. and yes imho it should likely be an optional feature that advanced users will want.

FYI, I did a short blog post about my easter hacking:
http://blog.liip.ch/archive/2014/04/22/prismic-io-content-repository-as-a-service.html

[David Buchmann]

maybe the inherently tree structured things like the menu and maybe
routing should be modeled with one nested document and we map nested
documents as nodes (which would make sense imho anyways). maybe nested
documents should be the only thing that create child nodes actually.

[Rudy Rigot]

Hey,

These are all very good points, and I'll make sure they're addressed by the team as our clientbase grows and so do their needs. I really understand where you come from with all that, it's a matter of sitting down and talking about it so we make sure we fulfill the need and solve the issue in the best way.

(Yep, I've seen the blog post, and retweeted it, and really like how you tell that story; if I didn't already know it, I'd be saying "well, this looks like a pretty passionate guy") :)

For you canonical URL issue in particular, note that you can have a /sports/blabla URL and a /politics/blabla URL whose canonical URL are both /blabla. I don't think you need the canonical URL to be a URL that exists (it's just some weird approach to have a "URI" for the document that a search engine can rely on), but even if it did, you could also make the page available there without ever linking to it from your website. But anyway, I see how this is just an example and doesn't represent fully the issue at large.

David > That's a valid statement, and document links (which allow to link documents to others, and therefore to nest them into each other if need be) could be used that way. The only thing that would be missing from prismic.io today to do this effectively is the interface to represent that tree in a more useable way... but this is not unimaginable! :) We mean to eventually come up with a way to let people customize their writing-room's interface, so that people find cool usages to the prismic.io concepts, and this definitely could be one. :)

Well, we have put the base to this, but as you can see, we're nowhere near arrived to our destination, and there's still much cool stuff to come. ;)

--

Rudy.

--
You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.

[Lukas Kahwe Smith]

On 24 Apr 2014, at 03:13, Rudy Rigot <rudy....@gmail.com> wrote:

> These are all very good points, and I'll make sure they're addressed by the team as our clientbase grows and so do their needs. I really understand where you come from with all that, it's a matter of sitting down and talking about it so we make sure we fulfill the need and solve the issue in the best way.

Yup, you obviously have a compelling solution for a lot of use cases already. So no reason to rush on this topic. Looking forward for how you all manage to address the topic and you know where to find us if you want to bounce some ideas around.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

PS: your co-worker Thibault was at the founding meeting of this very project :)

[Rudy Rigot]

Yep, I discover it right after you did!

If this isn't a small world...... ;)

--