Hi Mike, > I plan on making this UI cleaner too I'd defer this till the end. Functionality/usability is more important. After all this is a developer tool.
More importantly the basic structure/design of the explorer has to be re-thought - dynamic tree - reloading - partial/lazy loading (?) - plugin (node/type) editors - handling/editing multivalued properties. At the moment we don't have enough "information" (just the <ul><li>'s) in the client for this... > > + properties are no more being edited inline, which makes sense > I did this because I planned on eventually making the UI's > customizable, via plugins, based on primary type, etc. also proposed by Bertrand > - Principal / Group management 10) usermanagement > - Node type browser / management ? > - Content loading / exporting interface 6) nt:file -> file upload 7) import/export subtrees, format to be defined You say "I plan on making". Any time frame? In order to prevent duplicate work/effort I can/would wait till you are "done". WDYT Regards Clemens > -----Original Message----- > From: Mike Moulton [mailto:m...@meltmedia.com] > Sent: Sunday, August 15, 2010 7:09 AM > To: dev@sling.apache.org > Subject: Re: extending jQuery JCR Resource explorer > > > On Aug 13, 2010, at 10:47 PM, Clemens Wyss wrote: > > > I had a first look at your explorer. If I get this right: > > + new, more appealing, GUI > I plan on making this UI cleaner too, just didn't have time > to have one of my designers make me a better comp. > > > + new js-tree > The big problem with this tree is it pre-loads the entire > tree structure. This will not scale well. This is definitely > an item I think needs work. > > > + properties are no more being edited inline, which makes sense > I did this because I planned on eventually making the UI's > customizable, via plugins, based on primary type, etc. > > > + privileges, minimal > The reading of privileges is there, it's still missing > editing. Though, this should be rather easy given the > existing framework I have in there. > > > did I miss a "hidden feature"? > Nothing hidden that comes to mind. I had planned some > additional features though, given time. Like... > > - Principal / Group management > - Custom UI Plugins > - Node type browser / management > - Content loading / exporting interface > > > > >> -----Original Message----- > >> From: Clemens Wyss [mailto:clemens...@mysign.ch] > >> Sent: Saturday, August 14, 2010 7:20 AM > >> To: 'dev@sling.apache.org' > >> Subject: RE: extending jQuery JCR Resource explorer > >> > >> > >> Hi Mike, > >> cool. If you don't mind, I will take "your" code base and > >> build upon this > > Your welcome to use it as you wish. As I have time, I can > help further this along as well. > > >> > >> Thx > >> Clemens > >> > >>> -----Original Message----- > >>> From: Mike Moulton [mailto:m...@meltmedia.com] > >>> Sent: Saturday, August 14, 2010 12:00 AM > >>> To: dev@sling.apache.org > >>> Subject: Re: extending jQuery JCR Resource explorer > >>> > >>> > >>> I'm a little late to this thread but I wanted to bring this > >>> up anyway. A while back when I first was learning Sling I > >>> created an extended explorer based on the original version in > >>> the contrib. section. My explorer uses jQuery and > >>> accomplished most of the items of the current jQuery > >>> explorer. Before an extended set of work started on > >>> enhancements I wanted to donate this codebase in case it's of > >>> any use in this effort. I would love to see a mature explorer > >>> ship as a part of Sling, and any work I can do to help that, > >>> I will do. > >>> > >>> I created SLING-1653 [1] with the codebase in it. > >>> > >>> [1] https://issues.apache.org/jira/browse/SLING-1653 > >>> > >>> > >>> On Aug 13, 2010, at 9:21 AM, Bertrand Delacretaz wrote: > >>> > >>>> On Thu, Aug 12, 2010 at 4:26 PM, Clemens Wyss > >>> <clemens...@mysign.ch> wrote: > >>>>> ...Anything important/fancy missing? How would you > >>> priorize these features?.. > >>>> > >>>> A nice thing would be to use the Sling script resolution > to plugin > >>>> custom content editors based on resource types. > >>>> > >>>> Maybe just use .explorer.edit selectors to generate a > composite UI > >>>> where users can plugin their own editing components, and define a > >>>> simple set of guidelines/constraints that those components must > >>>> follow. > >>>> > >>>> -Bertrand > >>> > >>> > >> > > -- Mike >
