W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2015

Re: create.js

From: Lukas Kahwe Smith <smith@pooteeweet.org>
Date: Tue, 5 May 2015 16:00:43 +0200
Cc: markus.lanthaler@gmx.net, public-linked-json@w3.org, Henri Bergius <henri.bergius@iki.fi>
Message-Id: <FEC4382A-6571-44F8-9772-188C7F0322A3@pooteeweet.org>
To: christoph@christophdorn.com

> On 30 Apr 2015, at 19:12, Christoph Dorn <christoph@christophdorn.com> wrote:
> 
> 
> 
> On April 30, 2015 01:12:03 am PDT, "Lukas Kahwe Smith" <smith@pooteeweet.org> wrote:
>>> On 29 Apr 2015, at 18:26, Christoph Dorn <christoph@christophdorn.com> wrote:
>>> 
>>> I have created a summary of what I have in mind:
>>> 
>>> https://gist.github.com/cadorn/6028e90c0d4d9eca514f
>>> 
>>> I had been planning to implement something like this later this year anyway and would use this opportunity to start with something working and leverage existing communities to get where we want to go faster. I am looking to get an intent to integrate from at least one community (ideally Symfony) so we can get and keep momentum early on.
>> 
>> Can you elaborate further with what you mean with breaking up create.js?
>> Right now create.js is basically architected to be the connection between VIE.js, various JS editors (hallo.js, aloha.js, etc) and some “MVC” layers (atm backbone.js):
>> https://github.com/bergie/create/blob/master/bower.json
> 
> For me to make use of create.js I need a pure JS implementation that abstracts the whole page-editing problem no matter in which context it is used in. So create.js itself would turn into a virtual harness into which actual implementation plugins like viejs and backbone, jquery etc... are loaded.

ie. you want to port it from coffescript to pure JS?

> If I am going to do this work I will make create.js compatible with not only RDFa but arbitrarily annotated HTML and JS objects with

indeed microformats etc would be interesting .. it should certainly be pluggable, not sure how pluggable things are here right now .. though I think currently this is the responsibility of VIE.js

>  pluggable parsers etc... The point is if you need to make a change to a system you can use create.js no matter what aspect you are working on. To me create.js (and more so the new pinf.wiki) project will be a tool to edit anything that can export some form of metadata and expose an API for editing. One of the hurdles to get started with create.js that I hope to remove is RDFa and JSON-LD etc... This tech is not necessary and to me a strict subset of the general editing problem that I hope to solve using a super easy to integrate and highly compatible solution.

right .. like I said .. afaik create.js is currently the glue code between a frontend “MVC” (currently only backbone.js), the parser (VIE.js) and inline editors (aloha, hallo, etc). but regardless, I agree with this goal

> What is awesome about create.js is that it is already working in the RDFa/browser context so I have a solid starting point from which the concepts can be generalized. To make this new approach work I will re-architect the whole solution based on latest tech and experience to get the most gain.
> 
> 
>> So I am not sure if it really needs additional breaking up but rather bug fixing, some modernizations here and there and most importantly integration with some newer “MVC” frameworks. And finally some new features like i18n, workflows etc.
> 
> I am not interested in fixing bugs in the existing solution as I see it as having run its course (started several years ago, many issues, original author not available, no active contributors). It makes sense for people already using the component to fix bugs to keep things working but not for me. I personally would fix bugs after the reboot as many bugs will disappear due to a cleaner (more abstracted) design. I am proposing to dedicate at least 4 to 6 weeks to this initial effort which will allow me to get quite far.

The good news is that no user of create.js is really tightly coupled to it because what people really integrate with is RDFa and JSON-LD. As the UI level features are currently quite limited, there isn’t a lot of “lock-in” there. So if you can cover the feature set of the current stack, then I would envision most users will easily follow over to your new solution as soon as you start to surpass in features and/or quality.

BTW .. I just remembered that TYPO3 Neos also builds on create.js though I think they forked it to work with ember.js:
https://neos.typo3.org/learn/faq.html

I will try to point a few people on that community at this thread.

> 
>> That being said, Symfony CMF will have a two day hackday starting tomorrow (http://cmf.symfony.com/news/cmf-hackday-may-2015) and I will bring this up. I am quite confident that we would integrate any work that moves create.js forward.
> 
> My primary goal would be to KEEP COMPATIBILITY with the current integration BUT ADD MUCH MORE that may or may not be of use to Symfony. I believe Symfony CAN make use of the new features and would benefit but that is less important to me than Symfony swapping out its current usage with the new, more stable, tool. There will be plenty of opportunity to discuss the new features more and see a fit with Symfony.
> 
> It would be great if you can discuss this more with others. Maybe we can get buy-in from a couple of devs early on and I can get some help! I really need someone from the Symfony community to assist at times to ensure everything stays compatible as my perspective and use-cases are quite different which I see as another bonus.

Like I said, for Symfony CMF, I think as soon as you reach feature parity, there isn’t much that would keep us on the current implementation.

regards,
Lukas Kahwe Smith
smith@pooteeweet.org




Received on Tuesday, 5 May 2015 14:01:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 May 2015 14:01:17 UTC