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

Re: create.js

From: Christoph Dorn <christoph@christophdorn.com>
Date: Tue, 05 May 2015 15:19:51 +0000
Message-Id: <201505051519.t45FJpQI004683@rs103.luxsci.com>
To: smith@pooteeweet.org
Cc: markus.lanthaler@gmx.net, public-linked-json@w3.org, henri.bergius@iki.fi

On May 5, 2015 07:01:28 am PDT, "Lukas Kahwe Smith" 
<smith@pooteeweet.org> wrote:
>> On 30 Apr 2015, at 19:12, Christoph Dorn 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?

Its a bit more than that. I need multiple instances per page looking 
after different sets of elements. I need the system to be nested so it 
can edit different sub-contexts. I hope to edit multiple sets of 
content delivered to the "page" from different content sources and 
rendering targets or different security contexts. I want multiple 
people to be editing a page in realtime but only the pieces they are 
allowed to. I need dependent components on a page to update if an 
abstract component is edited etc..

By pure JS I meant more of a JS core/harness that manages contexts 
rather than implementation of specific features directly. This will 
make the system pluggable in every aspect and allow anyone to integrate.

I am not quite sure yet how this will be structured but I have done it 
for other tooling.

>> 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

I will likely be looking at VIE.js and other pieces in the process, not 
just create.js. I realize that my scope goes beyond create.js but that 
is the point. A new harness may do away with some sub-projects and just 
plug them all into one harness that is easier to extend. Don't know yet.

>> 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.

Right. Good.

> 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.

Interesting. I'll look into coding against that during dev as well and 
see what they have changed. The fact that they had to fork is reason 
enough to find a common denominator. We don't want to be splitting 
efforts in the future.

Thanks for the follow-up.

Received on Tuesday, 5 May 2015 15:20:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:45 UTC