I was trying to dumb down the example with 'content', however, in the CQ
world there are a couple of areas where the tool comes with an editor
for certain functionalities, for example workflows. While I can manage
them in XML, it would be much nicer to manage them in CQ (or in the IDE,
maybe through a hook that allows me to manage them in the repository and
then at save bring the generated structure back to the IDE).
Also, editing the XML's in an IDE has a couple of shortcomings due to
the fact that the XML structure currently used is very finicky and does
not allow for a DTD for example. This makes it IMHO pretty hard to
manage the structures in an IDE. (for example, list of child nodes has
to be at the end of the .content.xml file, can't be in the beginning and
the xml tag names are used to drive the node names in the repository,
not allowing a clear validation of the options).
Ruben
On 6/2/2013 9:33 AM, Dominik Süß wrote:
I'm trying to summarize my thoughts including the several opinions
scenarios stated:
a) The main usecase seems to be development from IDE (persisted to FS and
therefore to be integreated with any FS based versioning tool of choice)
b) a (on save) sync the application from FS to Sling via IDE seems what
everybody needs and agrees on
c) Not directly mentioned but what I think should be defined as well how
and when bundlebased (JAVA) code gets synced to the repository
d) where I didn't hear consensus is about syncing from Sling to FS. The
reason why I have my problem with that, is that autosync needs an explicit
definition how structures get mapped. In direction repository this is easy
since this unwraps the filebased (xml or json) wrappers and creates a lot
of finegrained strucures, but the other way around there would be the need
of an implicit way how those structures get serialized to the FS or some
(potentially) complex definition that a dev would have to make (possible
with vault afaik, but IMHO errorprone).
e) one of the main reasons for d is to see changes from the repository
within the IDE. I here fully second Carsten that this shouldn't be
automagically resolved but be controlled from the dev. The IDE here can
create some tooling to identify and display changes and support the job to
reestablish synchronity (this might be the hardest part for the tooling
since I havent seen a proper ui doing such a job).
f) regarding "sample" content mentioned by Ruben I think some
packagingmechanism and a maven task to upload/download this package should
besufficient (lock package, upload, change content in repo, download
package, check in vcs)
Cheers
Dominik
On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <r...@headwire.com> wrote:
we frequently have a content project during development with a sample site
that can be deployed over maven to a local dev instance. Maintaining the
sample content in the project requires to author in the cms and then sync
back to file system. Making bulk changes to the structure (for example,
globally rename a sling:resourceSuperType) is easier done in the IDE.
Content is then pushed back into the repository. I am not saying a constant
sync is needed, but a way for the IDE to 'update from repository' would
really help.
The vlt sync command has another issue. Since it stores its state in the
local file system but relies on the server to manage the files your server
instance and file system can get out of sync (say your server crashes and
you have to reinstall it). Switching instances (say current version vs new
version) for testing purposes (is everything still working fine) is not
well supported either.
Ruben
On 6/2/2013 6:35 AM, Antonio Sanso wrote:
On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
I think a sync in both directions is problematic and I wouldn't go there
-
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code including scripts and usually Java - this might also
include
coding in client side stuff like js and css. There is the central tool
you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.
+1
Whenever that's needed (syncing data from Sling into the file system)
this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE.
+1
Regards
Antonio
An automatic sync in both directions is dangerous and
imho in most cases not wanted/desired/required.
As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I
think
we should not support when talking about IDE support. Either we support
IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different, but then
let's
make it clear that we don't plan to provide a true dev experience.
Carsten
2013/6/1 Ian Boston <i...@tfd.co.uk>
Hi,
I've added the requirements for autosync to [1]. Although VLT does a
good
job of this once setup I don't use CLI for editing and manipulating. I
use
the IDE 100% with all its other tooling and just File Save.
Setup with VLT is 2 commands and a 1 line config file edit, which could
easily be converted into a IDE plugin.
Having thought about it, I think the reason vlt sync works well is that
Sling is on the same box, monitoring the file system for changes, (I
think
thats right, there is no local process with vlt sync) and monitoring JCR
for changes, which avoids lots of processing and http traffic. When I
have
used other forms of integration on large repositories, the volume http
traffic and speed of response has nearly always made them unusable.
What ever is used or reimplemented it must not rely on scanning a
repository to know what has changed. It must relay on notification of
some
form so that Edit->Save->Refresh is never more than a few seconds, and
doesn't impact the Sling server resource usage. Ideally notification
should
not rely on the IDE, since changes can be made without the IDE running,
and
routing it via the IDE is going to get really confusing with 3 or more
potential sources of updates. (assuming code under version control)
HTH
Ian
1.
https://cwiki.apache.org/**confluence/display/SLING/Use+**Cases<https://cwiki.apache.org/confluence/display/SLING/Use+Cases>
On 31 May 2013 14:07, Ian Boston <i...@tfd.co.uk> wrote:
@Justin, will do.
@Ruben, it doesnt :(, but IMHO it should. (knowing very little about
its
internals).
On 31 May 2013 13:48, Ruben Reusser <r...@headwire.com> wrote:
is the vlt sync now actually updating .content.xml files? I thought it
can only sync regular files.
Ruben
On 5/30/2013 7:24 PM, Justin Edelson wrote:
Ian - please do add the autosync use case to the wiki page I created.
On Thu, May 30, 2013 at 9:47 PM, Ian Boston <i...@tfd.co.uk> wrote:
Hi,
+1 to that. After working on sling for many years doing a mixture of
bundle
and UI work, mainly using the FileSystemResolver bundle, I realise
now
if
VLT had been available with sync mode (ie auto syncing the repo and
the
file system), we (the team I was working with at the time) would have
made
much more rapid progress. UI dev work needs file-save-refresh. The
in
browser editing UIs deliver this, as does VLT in sync mode, but
unfortunately native eclipse based tooling is just too slow (on my
machine,
might be my machine). Using VLT since I joined Adobe, has been a
joy,
and I
am very glad to know its being donated to the ASF.
Had we had VLT then, we would have developed in a very different
way,
and
might not have had half the problems we had with tooling and team
structure.
Ian
On 31 May 2013 10:16, Justin Edelson <jus...@justinedelson.com>
wrote:
Hi,
I would strongly suggest that this effort be based on VLT. As
mentioned
on
the wiki page, we're in the process of moving that to ASF and I
think
once
the code is available, it will be clear that it provides a good
low-level
interface for this type of UI.
While it is true that VLT currently only works with DavEX servers,
I
suspect it would not be hard to isolate the "Ex" bits and have a
"WebDAV"
only driver which could be used on non-JCR applications for basic
file
operations.
My concern is that we end up building one more abstraction which is
going
to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
etc.).
I know VLT has some baggage, but I'd just ask that people keep an
open
mind.
Separately, I'm going to start a child page of this wiki page to
gather
use
cases. There are some functional areas listed on the main page,
but I
think
we should try to capture individual use cases.
Regards,
Justin
On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
romb...@apache.org
wrote:
Hi,
Following Antonio's kick-start of the Sling developer tooling [1]
I've
gathered some thoughts about the initial goals and implementation of
our
Sling IDE tooling.
The document is at [2] so please have a look and let me know what
your
thoughts are. I intend to take a pass at the code next week and
align
it
to the proposed structure, as a foundation for feature work.
Robert
[1]:
https://cwiki.apache.org/****SLING/slingclipse.html<https://cwiki.apache.org/**SLING/slingclipse.html>
<
https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html>
[2]:
https://cwiki.apache.org/****confluence/display/SLING/**<https://cwiki.apache.org/**confluence/display/SLING/**>
Sling+IDE+tooling<
https://cwiki.apache.org/**confluence/display/SLING/**
Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
--
Carsten Ziegeler
cziege...@apache.org
