exist-development — eXist Developer's List

Re: [Exist-development] My vision about admin RESTful URLs

[Thomas W. <tho...@gm...>]

I think I need to refine the meaning of page in this case.

Dealing with large data sets always require some sort of displaying the
data in chunks/parts/pages and navigating between them. How we are going to
call it is not relevant.

The practice has showed us many times a simple truth - sending large
data down the wire is never a good idea.

A log chunk could be selected by range of line number (page-size and
page-number is effectively the same)  or by range of timestamps.

The page is a set of lines taken from the file and displayed in the browser
at the moment of accessing the file. We can display say 500 lines at a time
and walk up and down another 500 lines. We can event start displaying the
last 500 lines if we want.

That fact that this file grows it real time does not change the need of
delivering the data in chunks - we just need a simple mechanism of
periodically querying for data with timestamp older then the last update.

Delivering the data in chunks does not necessarily mean it will be displayed
as pages - the new data can be just appended on the screen. jQuery  can do
miracles with very little code.

I agree if we have a servlet that can access the logs and deliver part of
the log this will be the best. The servlet can accept the following
parameters:
log-file-name
 and one of the following:
  a) first-line-number, last-line-number
  b) page-size, page-number,
  c) timestamp-beginning, timestamp-end
  d) all-after-timestamp
  e) all  ( bad idea! )

another method:
logs-list: returns the name of the logs files, their sizes and last updated
timestamp.

I hope this clarification will help.

Regards,
Thomas

------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/26 Dmitriy Shabanov <sha...@gm...>

> On Thu, 2009-11-26 at 11:34 +0000, Thomas White wrote:
> > Dannes,
> >
> > This URL is to display the log in a browser in reasanable chunks. I do
> > think it will be practical to just dump 60,000 lines the browser.
>
> We need a log stream, not a page. When log's page open it should receive
> all log staff, till it be close (page). aka "tail -f eXist.log", but web
>
> --
> Cheers,
>
> Dmitriy Shabanov
>
>

Re: [Exist-development] My vision about admin RESTful URLs

[Dmitriy S. <sha...@gm...>]

On Thu, 2009-11-26 at 12:56 +0100, Wolfgang Meier wrote:
> > We need a log stream, not a page. When log's page open it should receive
> > all log staff, till it be close (page). aka "tail -f eXist.log", but web
> 
> I agree a comet application would be more appropriate for viewing a
> log. This can be done easily with a servlet and a hidden iframe. It
> would help to keep the load on the server low. The log viewer does not
> even need to be eXist-specific.

I thinking about log analyze (tool). Missing it :)

"keep the load on the server low" - rerouting shouldn't make this
problem (hope)

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] My vision about admin RESTful URLs

[Wolfgang M. <wol...@ex...>]

> We need a log stream, not a page. When log's page open it should receive
> all log staff, till it be close (page). aka "tail -f eXist.log", but web

I agree a comet application would be more appropriate for viewing a
log. This can be done easily with a servlet and a hidden iframe. It
would help to keep the load on the server low. The log viewer does not
even need to be eXist-specific.

Wolfgang

Re: [Exist-development] My vision about admin RESTful URLs

[Dmitriy S. <sha...@gm...>]

On Thu, 2009-11-26 at 11:34 +0000, Thomas White wrote:
> Dannes,
>  
> This URL is to display the log in a browser in reasanable chunks. I do
> think it will be practical to just dump 60,000 lines the browser.

We need a log stream, not a page. When log's page open it should receive
all log staff, till it be close (page). aka "tail -f eXist.log", but web

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] My vision about admin RESTful URLs

[Thomas W. <tho...@gm...>]

Dannes,

This URL is to display the log in a browser in reasanable chunks. I do think
it will be practical to just dump 60,000 lines the browser.

Thomas


------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/26 Dannes Wessels <di...@ex...>

> Hi,
>
>
> On Thu, Nov 26, 2009 at 11:15 AM, Thomas White <tho...@gm...>
> wrote:
> > I guess we need pagination for the log files as well. Then the URLs will
> be:
> > /admin/logs/list-all
> > /admin/logs/exist.log/{page-size}/{page-number}
> >
> > Dan,
> > How these URLs ideas fit with your point of view?
>
> please, no.. make a design that fits the logging, do not change the
> logging to fit the new interface.....
>
> logfiles do not have pages, log files are changed after every x mb etc.
>
> D.
>
> --
> eXist-db Native XML Database - http://exist-db.org
> Join us on linked-in: http://www.linkedin.com/groups?gid=35624
>

Re: [Exist-development] My vision about admin RESTful URLs

[Dmitriy S. <sha...@gm...>]

On Thu, 2009-11-26 at 12:19 +0100, Dannes Wessels wrote:
> hi,
> 
> On Thu, Nov 26, 2009 at 12:18 PM, Dannes Wessels <di...@ex...> wrote:
> > logfiles do not have pages, log files are changed after every x mb etc.
> 
> think of a never endig, though formatted, stream.

+ filtered by parameter or several

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] My vision about admin RESTful URLs

[Dannes W. <di...@ex...>]

hi,

On Thu, Nov 26, 2009 at 12:18 PM, Dannes Wessels <di...@ex...> wrote:
> logfiles do not have pages, log files are changed after every x mb etc.

think of a never endig, though formatted, stream.

D.


-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] My vision about admin RESTful URLs

[Dannes W. <di...@ex...>]

Hi,


On Thu, Nov 26, 2009 at 11:15 AM, Thomas White <tho...@gm...> wrote:
> I guess we need pagination for the log files as well. Then the URLs will be:
> /admin/logs/list-all
> /admin/logs/exist.log/{page-size}/{page-number}
>
> Dan,
> How these URLs ideas fit with your point of view?

please, no.. make a design that fits the logging, do not change the
logging to fit the new interface.....

logfiles do not have pages, log files are changed after every x mb etc.

D.

-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] My vision about admin RESTful URLs

[Thomas W. <tho...@gm...>]

Dmitriy,

I guess we need pagination for the log files as well. Then the URLs will be:
/admin/logs/list-all
/admin/logs/exist.log/{page-size}/{page-number}

Dan,
How these URLs ideas fit with your point of view?

Regards,
Thomas

------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/26 Dmitriy Shabanov <sha...@gm...>

> On Wed, 2009-11-25 at 23:50 +0000, Thomas White wrote:
> > B. Server information (view only).  Module name: state.xql
>
> Will we have any history data? example: logs view.
>
> How to handle it? from - to as one parameter?
> ( {application}/{module}/{object-type}/{action}/{single-parameter} )
>
> --
> Cheers,
>
> Dmitriy Shabanov
>
>

Re: [Exist-development] My vision about admin RESTful URLs

[Dmitriy S. <sha...@gm...>]

On Wed, 2009-11-25 at 23:50 +0000, Thomas White wrote:
> B. Server information (view only).  Module name: state.xql

Will we have any history data? example: logs view.

How to handle it? from - to as one parameter?
( {application}/{module}/{object-type}/{action}/{single-parameter} )

-- 
Cheers,

Dmitriy Shabanov

[Exist-development] My vision about admin RESTful URLs

[Thomas W. <tho...@gm...>]

Dear all,

Bellow is my vision about admin RESTful URLs.

We should try to pass the parameters as parts of the URL if we can
distinguish the paramemeters easily :

{application}/{module}/{object-type}/{action}/{single-parameter}

{application}/{module}/{object-type}/{action}/{id}/{old-value}/{new-value}



*A.  Server Configuration.* Module name: configuration.xql.
We can have the following  types of updates:

A.1 whole file:
HTTP PUT /admin/configuration/conf.xml/replace

A.2 an XML fragment:
HTTP PUT /admin/configuration/conf.xml/node-replace/db-connection/pool

 A.3 an element or attribute value: the last part of the URL is the new
value.
GET /admin/configuration/conf.xml/update-value/
db-connection/pool/@cacheSize/128M

A.4 Configuration save/restore

GET /admin/configuration/conf.xml/save?to=c:/config-data

GET /admin/configuration/conf.xml/load?from=c:/config-data



* B. Server information (view only).*  Module name: state.xql

/admin/state/status

/admin/state/statistics

/admin/state/performance-monitor

/admin/state/statistics/ profiling



* C. Job management.* Module name: jobs.xql

/admin/jobs/list-running-jobs

/admin/jobs/list-scheduled-jobs

/admin/jobs/kill/job-id

/admin/jobs/set-priority/job-id/priority



*D. Admin actions.* Module name: actions.xql

/admin/do/restart

/admin/do/reload

/admin/do/shutdown

/admin/do/backup/{root-collection-of-the backup}[?to=c:/backups]

/admin/do/restore/{root-collection-of-the
backup}?from=c:/backups/backup-file.zip

/admin/do/reindex/{collection-URI}



*E. Security, User and Group Management.* Module name: sequrity.xql

/admin/security/user/add/new-user-id/password/{home-collection}

/admin/security/user/delete/user-id

/admin/security/user/add-to-group/user-id-to-add /admin-users-group

/admin/security/user/rename/old-user-name/new-user-name

/admin/security/group/add/group-name/group-description

/admin/security/group/rename/old-group-name/new-group-name

/admin/security/group/add-user/admin-users-group/user-id-to-add

/admin/security/list-groups?page=x&page-size=xx

/admin/security/list-users?page=x&page-size=xx

/admin/security/global/default-access/{permissions}

/admin/security/collection/permissions-set/{URI}/{ permissions }

/admin/security/resource/permissions-set/{URI}/{ permissions }

/admin/security/resource/owner-set/{URI}/{new-owner}

/admin/security/resource/group-set/{URI}/{ new-group }

 *)  User bulk operations  - I do not have a clear idea jet

 *) Bulk(recursive) security operations - I do not have a clear idea jet



* F. Data browser.*  Module name browser.xql

  F.1. browse collections/resources. To get all set page-size to 0, sort is
optional:

/admin/browser/list-sub-collections/{collection-URI}/{page}/{page-size}?sort-by=[name|date|size]

/admin/browser/list-resources/{collection-URI}/{page}/{page-size}?sort-by=[name|date|size]

F.2 collections/resources operations:

/admin/browser/collection/move/db/collection-abc?to=/db/new-parent-collection

/admin/browser/resource/move/db/collection-abc/data.xml?to=/db/new-parent-collection

/admin/browser/collection/clone/db/collection-abc?to=/db/new-parent-collection

/admin/browser/resource/clone/db/collection-abc/data.xml?to=/db/new-parent-collection

Note: clone copies all permitions as well


/admin/browser/collection/backup/db/collection-abc?to=/db/new-parent-collection

/admin/browser/collection/restore/db/collection-abc?from=c:/backups/backup.zip

/admin/browser/collection/export/db/collection-abc/data.xml?to=c:/exported-xml-data

/admin/browser/collection/import/db/collection-abc/data.xml?from=c:/exported-xml-data

/admin/browser/resource/import/db/collection-abc?from=c:/exported-xml-data/data.xml

/admin/browser/resource/export/db/collection-abc/data.xml?to=c:/exported-xml-data



It is important to put all code that perform the actions into the module
files and every specific user interface implementation like  XForms,
AJAX, plane
HTML or iPhone will include the module to call the action first and later
return whatever specific implementation content is needed.

Module files will be in application collection/directory. All files from a
specifc user interface implementation will be in a single sub-collection
under admin, like /admin/XForms, /admin/iPhone or /admin/jQuery.

A controller.xql in admin collection/directory will translate the URLs into
XQuery URI and parameters. The preferred implementation will be added as a
prefix to the XQuery URI.

Any comments or questions?

Thomas


------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007

[Exist-development] A few updates on the eXist web administration functions

[Dan M. <dan...@gm...>]

We now have some more clear ideas on how we can use URL rewriting to create
a nice URL interface for the new proposed eXist administrative functions.

The basic idea is to give the users a clean URL API but then redirect the
incoming requests to a database administration application area wherever
they may be.

For example:
Incomming URL: /admin/collection/copy?from=/db/a&to=/db/b

Rewrite-to:
/db/apps/exist-admin/actions/collection-copy.xq?from=/db/a&to=/db/b

Here is a example URL data set that shows how this might be done:

http://demo.syntactica.com/exist/rest/db/cust/exist-admin/apps/rewrite/admin-rewrite-samples.xml

I have also created a sample of a fully RESTful version of the
collection-copy function and two sample web forms.  One in plain-old HTML
and one using XSLTforms.

Very Simple HTML (with no CSS for the field widths):
http://demo.syntactica.com/exist/rest/db/cust/exist-admin/apps/collection-browser/forms/collection-copy-html.xq

XSLTForms:
http://demo.syntactica.com/exist/rest/db/cust/exist-admin/apps/collection-browser/forms/collection-copy-xsltforms.xq

Both of these forms will call the same REST interface.  Here is an example
of the "from" and "to" parameters on the copy action before the rewrite:

$HOST..../db/cust/exist-admin/apps/collection-browser/actions/collection-copy.xq?from=/db/a&to=/db/b

and after the rewrite:

$HOST/admin/collection/copy?from=/db/a&to=/db/b

We have started to put in some basic checking for required parameters but it
is clear that getting good warnings and error message back to the users will
be critical for overall usability.

These forms can be enhanced and any time by users with nice JQuery
drag-and-drop functions, as-you-type checking, progress bars etc. in the
future.  But the basic framework of calling a REST interface and returning
error high-quality messages should not change.

You can do a "view source" on these to see how these forms work and we are
currently thinking about a good place to put the source code and if all
exist distributions should include all possible versions of the
administrative tools.

For each of the collection functions we now can start to gather more
detailed requirements like:
  What are the parameters?
  Which one are required?
  What are the edit checks?
  What are the rules to enable a button for any given collection?
  How should error messages from forms be handled in a consistent way?

We will also be working on some user account administration forms.

- Dan
-- 
Dan McCreary
Semantic Solutions Architect
syntactica.com
952-460-1674
VOIP: 111@69.199.167.229

Re: [Exist-development] Strange jetty logging...

[Pieter D. <pie...@gm...>]

This reminds me of this tip from "The Pragmatic Programmer":

"We worked on a project where a senior engineer was convinced that the
select system call was broken on Solaris. No amount of persuasion or
logic could change his mind (the fact that every other networking
application on the box worked fine was irrelevant). He spent weeks
writing workarounds, which, for some odd reason, didn't seem to fix
the problem. When finally forced to sit down and read the
documentation on select, he discovered the problem and corrected it in
a matter of minutes. We now use the phrase "select is broken" as a
gentle reminder whenever one of us starts blaming the system for a
fault that is likely to be our own."

Regards,
Pieter

On Wed, Nov 25, 2009 at 9:04 AM, Dannes Wessels <di...@ex...> wrote:
> All,
>
> Lat week I found the following logging in std out:
>
> "10028020@qtp-2102960-1 - Acceptor0
> SelectChannelConnector@0.0.0.0:8080] INFO org.mortbay.log - seeing JVM
> BUG(s) - cancelling stOps==0"
>
>
> Fortunately my friend google helped me here. Check the code in :
>
> http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg00930.html
>
> here you see comments in the code  like
>
> "// BLOODY SUN BUG !!!  Try refreshing the entire selector."
>
> and expressions like
>
>  "else if (_jvmBug%32==31) // heuristic attempt to cancel key
> 31,63,95,... loops"
>
>
> The jetty folks are happy to share their frustrations with us :-)
>
> regards
>
> Dannes
>

[Exist-development] Strange jetty logging...

[Dannes W. <di...@ex...>]

All,

Lat week I found the following logging in std out:

"10028020@qtp-2102960-1 - Acceptor0
SelectChannelConnector@0.0.0.0:8080] INFO org.mortbay.log - seeing JVM
BUG(s) - cancelling stOps==0"


Fortunately my friend google helped me here. Check the code in :

http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg00930.html

here you see comments in the code  like

"// BLOODY SUN BUG !!!  Try refreshing the entire selector."

and expressions like

 "else if (_jvmBug%32==31) // heuristic attempt to cancel key
31,63,95,... loops"


The jetty folks are happy to share their frustrations with us :-)

regards

Dannes


--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] List of collection actions for administration tool

[Dannes W. <di...@ex...>]

I like the RESTfull idea.... 

On 18 Nov 2009, at 16:52 , Adam Retter wrote:

> Well I think we should make use of Restful URI's -
> 
> i.e. HTTP PUT /exist/rest/db/col1
> i.e. HTTP DELETE /exist/rest/db/col2
> 
> That functionality probably already exists to be honest...
> 
> Other things which cannot be expressed directly via HTTP could be done
> via  a script -
> 
> i.e. HTTP GET /exist/rest/db/system/webclient/collection/move?source=/db/col1&destination=/db/col2
> i.e. HTTP GET /exist/rest/db/system/webclient/collection/copy?source=/db/col1&destination=/db/col2
> 
> or maybe you want something more like -
> 
> HTTP GET /exist/rest/db/col1?move&destination=/db/col2
> HTTP GET /exist/rest/db/col1?copy&destination=/db/col2
> 
> 
> If we are doing this in a Restful manner, it is very very important to
> think about the URI scheme from the start before we think about
> anything else.

Kind regards

Dannes

--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] List of collection actions for administration tool

[Adam R. <ad...@ex...>]

Well I think we should make use of Restful URI's -

i.e. HTTP PUT /exist/rest/db/col1
i.e. HTTP DELETE /exist/rest/db/col2

That functionality probably already exists to be honest...

Other things which cannot be expressed directly via HTTP could be done
via  a script -

i.e. HTTP GET /exist/rest/db/system/webclient/collection/move?source=/db/col1&destination=/db/col2
i.e. HTTP GET /exist/rest/db/system/webclient/collection/copy?source=/db/col1&destination=/db/col2

or maybe you want something more like -

HTTP GET /exist/rest/db/col1?move&destination=/db/col2
HTTP GET /exist/rest/db/col1?copy&destination=/db/col2


If we are doing this in a Restful manner, it is very very important to
think about the URI scheme from the start before we think about
anything else.




2009/11/18 Thomas White <tho...@gm...>:
> I would like to propose an "object-action" name convention. For example:
>       collection-create
>       collection-delete
>       collection-copy
>       collection-move
>       index-create
>       index-update
>
> To me it is more natural to define the entity I  am going to work with
> first, and then talk about the action.
>
> Thomas
> ------
>
> Thomas White
>
> Mobile:+44 7711 922 966
> Skype: thomaswhite
> gTalk: thomas.0007
> Linked-In:http://www.linkedin.com/in/thomaswhite0007
> facebook: http://www.facebook.com/thomas.0007
>
>
>
> 2009/11/18 Adam Retter <ad...@ex...>
>>
>> > By creating RESTful interfaces for each action we can do UNIT testing on
>> > the
>> > actions and also allow anyone to easily extend the interface to match
>> > their
>> > requirements.
>>
>> You can also decide on the UI later, or create more than one possible
>> UI that uses the same back end.
>>
>> I suggest that all back-end REST interfaces are constructed and tested
>> in advance of any UI code!
>> I would also suggest that the back-end should follow an MVC
>> approach... well at least the M and C parts for the time being!
>>
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] List of collection actions for administration tool

[Thomas W. <tho...@gm...>]

I would like to propose an "object-action" name convention. For example:
      collection-create
       collection-delete
      collection-copy
      collection-move
      index-create
      index-update

To me it is more natural to define the entity I  am going to work with
first, and then talk about the action.

Thomas

------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/18 Adam Retter <ad...@ex...>

> > By creating RESTful interfaces for each action we can do UNIT testing on
> the
> > actions and also allow anyone to easily extend the interface to match
> their
> > requirements.
>
> You can also decide on the UI later, or create more than one possible
> UI that uses the same back end.
>
> I suggest that all back-end REST interfaces are constructed and tested
> in advance of any UI code!
> I would also suggest that the back-end should follow an MVC
> approach... well at least the M and C parts for the time being!
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>

Re: [Exist-development] List of collection actions for administration tool

[Adam R. <ad...@ex...>]

> By creating RESTful interfaces for each action we can do UNIT testing on the
> actions and also allow anyone to easily extend the interface to match their
> requirements.

You can also decide on the UI later, or create more than one possible
UI that uses the same back end.

I suggest that all back-end REST interfaces are constructed and tested
in advance of any UI code!
I would also suggest that the back-end should follow an MVC
approach... well at least the M and C parts for the time being!


-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] List of collection actions for administration tool

[Dan M. <dan...@gm...>]

I believe that we can decompose the problem into a few levels.

The current approach is to define a set of administrative "actions" on
administrative "objects".

We now have around 22 actions on the collection object.  We will also have
add/edit actions for users and perhaps roles.

Most of these actions will have:

1) *Enablement rules:* these determine the action trigger is enabled based
on context.  For example if you don't have write access to a collection the
"Move" button should not ever be enabled when your collection browser is on
that collections.
2) *A RESTful interface*.  A simple XQuery script that takes URL parameters
(or possible a POST if there are larger data sets involved)
3) *One or more UI forms.*  One or more user interface forms based on the
capabilities of the browser

Some of these "forms" may or may not need XForms.  For example the delete
"form" just has a smile conform dialog.  No need for a complex XForms
application here.

Kurt and I have both created variations of hierarchical browsers using
XForms.

You can see a few of them in the XForms cookbook here:

http://en.wikibooks.org/wiki/XForms/Outline_Editor
http://en.wikibooks.org/wiki/XForms/Graph_Viewer

We are not suggesting that we must use XForms for navigation.  There are
many, many options that we may still explore.  There are hundreds of
JavaScript libraries for viewing trees.  JQuery also has some nice tree-view
that may be easier to use.

http://jquery.bassistance.de/treeview/demo

By creating RESTful interfaces for each action we can do UNIT testing on the
actions and also allow anyone to easily extend the interface to match their
requirements.

HTML-5 may include a DataGrid viewer that has an option for viewing trees.
If this is "built in" to future browsers we want to be able to migrate to
that user interface.

I think the key is that we first of all identify the administration objects,
the actions and then build RESTful interfaces that can have aggressive UNIT
testing.  Simple actions like making sure that we prevent a collection from
being moved into itself will need to be done.

Creating RESTful interfaces for each function should not be technically
hard.  Just time-consuming.

Creating XForms front ends to these RESTful services should also not be
difficult.

The biggest difficulty I see is doing high-quality usability testing in some
objective way when we consider that we have many different types of users.
I do not claim to have a strong background in usability testing other than
being able to do the obvious things like counting the number of clicks or
avoiding scrolling through 10,000 collection items to backup a collection.

I think our objectives for the first pass should be to create a modular
architecture for administrative functions so that it can be easily tested
and extended.  Once we do this the details can be worked on by a larger
community that includes usability testing.

There has also been the suggestion that we wrap some of these functions in
EXQuery libraries to see if the tools can be portable to other XQuery
platforms such as MarkLogic or DB2.  We certainly have at least one customer
that would like to use one set of administrative tools to manage both eXist
and MarkLogic even though the concept of collections is clearly not uniform
across eXist, MarkLogic and DB2.  The separation of concerns would allow a
larger community to build interfaces (Objective-C for the iPhone for
example) to the RESTful actions.  We have got thumbs up on this approach
from several people.

Keep the great ideas coming!

- Dan

On Wed, Nov 18, 2009 at 6:22 AM, Wolfgang Meier <wol...@ex...>wrote:

> Thomas,
>
> > The solution for the web client I have in mind id not based on XForms.
> It
> > is a XQuery+ XSLT application fframework, that can generate content in
> two
> > modes - interactive AJAX pages and plain HTML pages.
>
> aha, so this is an important question. I have no problem with AJAX in
> principle. Actually, I already started to create an XQuery module
> which generates code for Yahoo UI in the admin client (see
> webapp/admin/yahoo-ui.xql). It is used for the tabs in the profiling
> view and I planned to extend it to cover other widgets.
>
> However, we should make sure that everyone interested can contribute
> to the project. Please correct me if I'm wrong, but I think an XForms
> based interface will allow more people to help. XForms is an important
> tool in the XML toolbox which could be demonstrated this way. On the
> other hand, some features won't be possible with plain XForms, e.g.
> tree views (though I personally think web applications should not try
> to mimic every feature of a desktop app).
>
> Well, we fortunately have some XForms experts here (Dan, Kurt)...
>
> Wolfgang
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>



-- 
Dan McCreary
Semantic Solutions Architect
syntactica.com
952-460-1674
VOIP: 111@69.199.167.229

Re: [Exist-development] List of collection actions for administration tool

[COUTHURES A. <ala...@ag...>]

Wolfgang,
> Thomas,
>
>   
>> The solution for the web client I have in mind id not based on XForms.  It
>> is a XQuery+ XSLT application fframework, that can generate content in two
>> modes - interactive AJAX pages and plain HTML pages.
>>     
>
> aha, so this is an important question. I have no problem with AJAX in
> principle.
I should also say that I have no problem with AJAX too, because 
XSLTForms is based on AJAX ;-)
>  Actually, I already started to create an XQuery module
> which generates code for Yahoo UI in the admin client (see
> webapp/admin/yahoo-ui.xql). It is used for the tabs in the profiling
> view and I planned to extend it to cover other widgets.
>   
XSLTForms is using XSLT to generate vanilla HTML+Javascript. YUI objects 
could also be generated (I was thinking of CSS extensions to activate 
their generation).
> However, we should make sure that everyone interested can contribute
> to the project. Please correct me if I'm wrong, but I think an XForms
> based interface will allow more people to help.
Yes, I think that XForms is easier to learn than complex Javascript 
(I've been developing with YUI too, I even created a customized 
DataTable class with horizontal and vertical scrollers...!).
>  XForms is an important
> tool in the XML toolbox which could be demonstrated this way.
XRX has to be demonstrated.
>  On the
> other hand, some features won't be possible with plain XForms, e.g.
> tree views (though I personally think web applications should not try
> to mimic every feature of a desktop app).
>   
I think that such extensions have to be considered. AJAXForms, XSLTForms 
ancestor, had already similar capabilities but I had not yet time to 
reconsider them.
> Well, we fortunately have some XForms experts here (Dan, Kurt)...
>   
I don't consider me as an XForms expert yet... But I can improve 
XSLTForms in many interesting ways (XPath 2.0, XQuery and XSLT 1.0 
within XForms, ...) ;-)

-Alain

Re: [Exist-development] List of collection actions for administration tool

[Wolfgang M. <wol...@ex...>]

Thomas,

> The solution for the web client I have in mind id not based on XForms.  It
> is a XQuery+ XSLT application fframework, that can generate content in two
> modes - interactive AJAX pages and plain HTML pages.

aha, so this is an important question. I have no problem with AJAX in
principle. Actually, I already started to create an XQuery module
which generates code for Yahoo UI in the admin client (see
webapp/admin/yahoo-ui.xql). It is used for the tabs in the profiling
view and I planned to extend it to cover other widgets.

However, we should make sure that everyone interested can contribute
to the project. Please correct me if I'm wrong, but I think an XForms
based interface will allow more people to help. XForms is an important
tool in the XML toolbox which could be demonstrated this way. On the
other hand, some features won't be possible with plain XForms, e.g.
tree views (though I personally think web applications should not try
to mimic every feature of a desktop app).

Well, we fortunately have some XForms experts here (Dan, Kurt)...

Wolfgang

Re: [Exist-development] List of collection actions for administration tool

[Thomas W. <tho...@gm...>]

Wolfgang,

The solution for the web client I have in mind id not based on XForms.  It
is a XQuery+ XSLT application fframework, that can generate content in two
modes - interactive AJAX pages and plain HTML pages. If we have all actions
in separated modules we can easily re-use them in whatever context we need.

Thomas
----


2009/11/18 Wolfgang Meier <wol...@ex...>

> > I think it is important, when we create the set of actions, to separate
> the
> > code that perform the action from the code that generates a particular
> user
> > interface.
>
> But isn't that the normal approach when using XForms? Ok, if you
> generate the XForms from an XQuery, it is possible to pack business
> logic into the query. I agree we shouldn't do that ;-).
>
> Wolfgang
>

Re: [Exist-development] List of collection actions for administration tool

[Adam R. <ad...@ex...>]

I just had a thought which is this -

Any web based interface that we create will NOT be suitable for embedded mode!

So I think we need to define what we are trying to achieve here. Are
we trying to create a client which is suitable for any mode of
operation, or a client that is only suitable for use with remote
servers?



2009/11/18 Wolfgang Meier <wol...@ex...>:
>> I think it is important, when we create the set of actions, to separate the
>> code that perform the action from the code that generates a particular user
>> interface.
>
> But isn't that the normal approach when using XForms? Ok, if you
> generate the XForms from an XQuery, it is possible to pack business
> logic into the query. I agree we shouldn't do that ;-).
>
> Wolfgang
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] List of collection actions for administration tool

[Wolfgang M. <wol...@ex...>]

> I think it is important, when we create the set of actions, to separate the
> code that perform the action from the code that generates a particular user
> interface.

But isn't that the normal approach when using XForms? Ok, if you
generate the XForms from an XQuery, it is possible to pack business
logic into the query. I agree we shouldn't do that ;-).

Wolfgang

Re: [Exist-development] List of collection actions for administration tool

[Thomas W. <tho...@gm...>]

Dmitriy,

This is a good point. It may help us if you can provide some screenshots
with the features you believe are useful or particularly well designed.

Thomas


------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/18 Dmitriy Shabanov <sha...@gm...>

> On Tue, 2009-11-17 at 08:35 -0600, Dan McCreary wrote:
> > There is a sample collection browser here:
>
> I did use mySQL for long time & phphMyAdmin is very good tool for
> database management. Can we extract best-practice from that tool
> (layouts, menu structure & so on)?
>
> http://www.phpmyadmin.net/home_page/try.php
>
> --
> Cheers,
>
> Dmitriy Shabanov
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>