Hi,
I've just dumped my thoughts about new ui and new config
here:
http://docs.codehaus.org/display/GEOS/New+user+interface
http://docs.codehaus.org/display/GEOS/New+configuration
Feel free to chime in and discuss 
Cheers
Andrea
Looks like a great start Andrea, a good job of summing up all the
current issues. I have added a few comments to the page, and updated the
ui wish list with an additional requirement.
-Justin
Andrea Aime wrote:
Hi,
I've just dumped my thoughts about new ui and new config
here:
http://docs.codehaus.org/display/GEOS/New+user+interface
http://docs.codehaus.org/display/GEOS/New+configurationFeel free to chime in and discuss
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,458e5fa5236272081064789!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Le Lundi 25 Décembre 2006 18:44, Justin Deoliveira a écrit :
Hi all,
Just a question after reading theses specs : does someone known about ZeroCode
(http://www.zkoss.org)? There are a Spring connector, and a upgrading path
from Struts/JSP to ZK.
I am reading the documentation and it seems that R1-R9 are covered.
Not sure (neither unsure) about W1, but W2, W3 and W4 seem to be covered too.
As I don't know wicket yet, I'm not able to compare them.
didier
Looks like a great start Andrea, a good job of summing up all the
current issues. I have added a few comments to the page, and updated the
ui wish list with an additional requirement.-Justin
Andrea Aime wrote:
> Hi,
> I've just dumped my thoughts about new ui and new config
> here:
> http://docs.codehaus.org/display/GEOS/New+user+interface
> http://docs.codehaus.org/display/GEOS/New+configuration
>
> Feel free to chime in and discuss
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:1004,458e5fa5236272081064789!
Richard didier ha scritto:
Le Lundi 25 Décembre 2006 18:44, Justin Deoliveira a écrit :
Hi all,Just a question after reading theses specs : does someone known about ZeroCode (http://www.zkoss.org)? There are a Spring connector, and a upgrading path from Struts/JSP to ZK.
I am reading the documentation and it seems that R1-R9 are covered.
Not sure (neither unsure) about W1, but W2, W3 and W4 seem to be covered too.As I don't know wicket yet, I'm not able to compare them.
First of all, thank you for suggesting it.
I've taken a look, and it's somehow similar to wicket on the server side, and to GWT on the client side... good match indeed, seems
well thought out.
I don't like much the fact that ZUML is used instead of pure XHTML
as in the case of Wicket, but what really rings as wrong is the
license model: GPL + commercial.
If our road is to make Geoserver core LGPL so that people can build
commercial extensions to Geoserver, I would stay away from a framework
that makes you pay big bucks when it comes to write the UI for your
commercial module.
Cheers
Andrea
Le Vendredi 29 Décembre 2006 16:21, Andrea Aime a écrit :
Richard didier ha scritto:
> Le Lundi 25 Décembre 2006 18:44, Justin Deoliveira a écrit :
> Hi all,
>
> Just a question after reading theses specs : does someone known about
> ZeroCode (http://www.zkoss.org)? There are a Spring connector, and a
> upgrading path from Struts/JSP to ZK.
>
> I am reading the documentation and it seems that R1-R9 are covered.
> Not sure (neither unsure) about W1, but W2, W3 and W4 seem to be covered
> too.
>
> As I don't know wicket yet, I'm not able to compare them.First of all, thank you for suggesting it.
I've taken a look, and it's somehow similar to wicket on the server
side, and to GWT on the client side... good match indeed, seems
well thought out.
I've made some tests (porting Struts/Tiles/JSP), it is quite impressive in
terms of final appearence (thanks to the XUL widgets)
I don't like much the fact that ZUML is used instead of pure XHTML
as in the case of Wicket, but what really rings as wrong is the
license model: GPL + commercial.
I missed that one !-(
If our road is to make Geoserver core LGPL so that people can build
commercial extensions to Geoserver, I would stay away from a framework
that makes you pay big bucks when it comes to write the UI for your
commercial module.
You're right. Forget about ZK.
Cheers
Andrea
All the best,
didier
Catching up on email,
With respect to the "New configuration" I am really interested in seeing the GeoTools catalog interfaces used this time around. They are forth generation out from the geoserver original, provide an open ended way to attach additional information for new services (ie NamedStyle or SLD for WMS) etc...
The page seems to focus on XML, I would actually like to see some independence here - so the configuration can be stored in a database or filesystem. Storing in a common database is one of the best ways to get a clustering solution off the ground for example.
Cheers,
Jody
Hi,
I've just dumped my thoughts about new ui and new config
here:
http://docs.codehaus.org/display/GEOS/New+user+interface
http://docs.codehaus.org/display/GEOS/New+configurationFeel free to chime in and discuss
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Nice write up, not sure I can add much to framework discussion due to lack of experience. It is clear that Struts has run its course 
Aside: Confluence is based on Webwork (or at least the velocity part of it), and I have not always found the hacking environment friendly.
A couple of priorities:
- internationalization, can we compare the frameworks in this respect as well
- WTP - using the web tools project right now, since most developers are on eclipse we may check what works well in this environment
- workflow, have a look at a running "continnuum" this is about perfect for monitor and config application (I am very impressed)
Questions:
- What was the name of the internationalization JCP that was trying to replace the Struts + Tiles approach? Was that JSF?
And it should be pointed out that none of this really get's us out of making a JMX bean available to monitor the running GeoServer, and probably teach it about oracle connection pools as well.
The User interface design was simple a page of "Downsides of the current UI", I have provided some content with an outline of a "cross bar navigation" approach.
Cheers,
Jody
Hi,
I've just dumped my thoughts about new ui and new config
here:
http://docs.codehaus.org/display/GEOS/New+user+interface
http://docs.codehaus.org/display/GEOS/New+configurationFeel free to chime in and discuss
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
comments inline:
Jody Garnett wrote:
Nice write up, not sure I can add much to framework discussion due to lack of experience. It is clear that Struts has run its course
Aside: Confluence is based on Webwork (or at least the velocity part of it), and I have not always found the hacking environment friendly.
ah, thanks for pointing that out. We looked around a bit but could find/remember what confluence used.
A couple of priorities:
- internationalization, can we compare the frameworks in this respect as well
Good call, we can't forget internationalization. So far what I have looked at they all seem to support it and are reasonably easy to use. What I hope for is if we can use our existing properties files and not have to re-write them or change keys etc.
- WTP - using the web tools project right now, since most developers are on eclipse we may check what works well in this environment
- workflow, have a look at a running "continnuum" this is about perfect for monitor and config application (I am very impressed)
I haven't heard of Continum, I will definitely take a peak at it.
Questions:
- What was the name of the internationalization JCP that was trying to replace the Struts + Tiles approach? Was that JSF?
Yeh I think you are talking about JSF. Personally I want to avoid JSPs entirely. Wicket and GWT use straight up HTML with a simple tag that is replaced by the corresponding code on the Java side. It makes it really easy to see what the page looks like and what to expect from it.
And it should be pointed out that none of this really get's us out of making a JMX bean available to monitor the running GeoServer, and probably teach it about oracle connection pools as well.
The User interface design was simple a page of "Downsides of the current UI", I have provided some content with an outline of a "cross bar navigation" approach.
I definitely want to see data wizards at the minimum. Currently I don't find the existing UI too bad, it is pretty straight forward and not bloated. But I am used to it...
Cheers,
Jody
Brent Owens
(The Open Planning Project)
Hi,
I've just dumped my thoughts about new ui and new config
here:
http://docs.codehaus.org/display/GEOS/New+user+interface
http://docs.codehaus.org/display/GEOS/New+configurationFeel free to chime in and discuss
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Brent Owens wrote:
I definitely want to see data wizards at the minimum. Currently I don't find the existing UI too bad, it is pretty straight forward and not bloated. But I am used to it...
Better add a description of "Data Wizards" to that page then ... 
Jody
Jody Garnett ha scritto:
Catching up on email,
With respect to the "New configuration" I am really interested in seeing the GeoTools catalog interfaces used this time around. They are forth generation out from the geoserver original, provide an open ended way to attach additional information for new services (ie NamedStyle or SLD for WMS) etc...
They well may be part of the solution, but not a requirement I guess?
I wish I could understand them better, when I faced the uDig version I
simply gave up (the solution seemed to be way too complex for the
problem it tried to solve, but it may well be that uDig uses only a tiny fraction of their expressive power).
When we go down and design a solution, let's see how they fit and what
advantages they bring, it may well be that I get to understand their
value this time
The page seems to focus on XML, I would actually like to see some independence here - so the configuration can be stored in a database or filesystem. Storing in a common database is one of the best ways to get a clustering solution off the ground for example.
Indeed, that's what I've stated on the last paragraph of that page too
To achieve real independence we would have to force developers to provide enough metadata to allow each configuration component to be
serialized to different storages.
XStream does not need extra info, JAXB needs schemas, Hibernate needs
mapping configuration files (since we're stuck on jdk 1.4), and so on.
Modularity and tech independence fight each other, we should have a mandate that each new modules works at least with one storage backend
(asking people to make things work against multiple ones is too much).
That's why I insisted on XML and XStream, seems to be the least common
denominator and the easiest one to deal with, developer of new module
doesn't really need to understand any other technology, just needs
java beans.
As some others pointed out, file storage has also the
interesting property of being usable as a layman tool for configuration
exchange (not for distributed network service things, I just think
about debugging issues, the kind of "give me your configuration so
that I can have a look at it"). Configuration is not something you
can move from one geoserver to the other anyways, since you're not moving the datastores as well usually :-p (ok, you can move shapefiles,
but not dbms ones as easily).
That said, yeah, the solution should be made so that you're insulated
from actual data storage, so if one needs a database backend it's easy
to write.
Or, we could ask for database backend as normal storage (using hsql or
h2) as use XML just as a import/export tool.
Ok, I'm updating the page trying to incorporate these considerations.
Cheers
Andrea
Rob, I'm answering here since confluence is not really designed for
threaded discussion and page evolution may make comment outdated and/or
irrelevant (which may confuse readers imho).
OK - some other perspectives, which IMHO would lead to a reappraisal
of the requirements along the lines of Chris's comments.In general, deployment of _interoperable_ services requires
conformance to a particular _profile_ of the underlying base
standard. for example, a bunch of counties might deploy schools data,
transport condition updates.Motherhood statements, but with significant implications:
Each content offering (Feature Type, Layer etc) will need to conform
to at least two profiles: the jurisdictional/enterprise view (all
our services have the following metadata etc) and the content related
standards (you must be able to perform these queries against this
data standard).
Rob, a couple of paragraphs and I've already lost you, LOL!
Configuration and profiles are related, yet different in my opinion.
Say multiple conties deploy schools data.
Most probably (at least in Italy, don't know about USA) each county
already has that data, and it's managed in different format that
does not match the profile. They won't change the format, because they
have existing applications running on top of it.
So, to satisfy the public profile they probably:
a) configure their datastore in Geoserver as they are
b) fiddle with complex data store configurations so to build the
public profile out of their actual data structures
Geoserver configuration should store a) and b), not the public profile?
The public profile is what you get when you do a GetCapabilities request, that is, not the actual Geoserver configuration, but
the published service configuration, something that's computed,
not stored, and not even used by Geoserver internally?
Thus, R1 seems to be not so much a requirement as an implementation
strategy, and not one that fits the real set of requirements.
Now, the ability to maintain ID refs and provide meaningful reports
on errors, regardless of single or multiple files seems to be a
common concern.I'd suggest replacing R1 with:
1a) Add ability to check for logical inconsistencies between
configuration components1b) Propagate errors and warnings to system manager (via UI, URL
accessible config log or email in the future) in such a way that the
underlying cause can be readily identified
1c) Allow importation of external XML resources (e.g. schemas, but
also feature type definitions, service profiles) into a local cache,
with ability to refresh from external source, saving old versions.1d) Allow plugin services, including configuration and metadata
Indeed you're right, I've tried to amend the document to incorporate
1a), 1b) and 1d).
1c), I'm not sure I understand. I have my own data which does not match
the public profile. I do import the public profile, and then have mapping tools that make me go from actual data storage to the
agreed upon data exchange formats. What configuration should store
the mappings, the public profile by itself may be stored too
as a reference. Is that what you mean?
The way forward would be to revisit this issue with a "separation of
concerns" perspective. IMHO, we havent really got together all the
usage patterns, so we're reacting to the problems inthe current
system rather than designing for the future. If so, then its better
to recognise its a pure band-aid and avoid overcapitalising.
We're working on different time scales. I know current UI and config
is a waste of time and want one that allows me to easily add the new
services we're planning to support in the next couple of months.
It seems to me you're planning on the 6month-1year timescale afaik.
We're also targeting different needs: I do care about our current
users and their typical needs.
The needs you're trying to address are more complex, less common.
It may be possible to provide a navigator/editor that traverses the
links between plugged-in object configurations (ie. a single virtual
XML file that doesnt need to be manually constructed from many
fragments). I wouldnt like to see such an investment without more
analysis of the actual requirements.
Such an investment? The simplistic Xstream based solution I was
proposing would have taken less than a week to implement, the one we're
discussing now will take 1/2 months in discussion, design and
implementation.
I'd go back to basics and
describe the Use Cases for configuration changes. The Use Case
described is a very specialised one - a developer adding a piece of
functionality.For every developer, there will be many configurators, and for every
deployment, many end-users. I beleive if we had sharable
configurations, the orders-of-magnitude would look like this:
Sharable configurations... I don't see their applications besides a
cluster. A sharable configuration assumes you have the same kind
of databases, same data structures and the like.
My experience tells me at least here in Italy everybody does its
own, so you may well have people agree on a profile, but each
will do its own when it comes to data management, so configuration
(set of datastore parameters, feature type configurations, mappings
from storage types to published ones) is simply different for each
user.
developer -> data type configurator -> deployer -> user
And the config system is pretty bad for the deployer IMHO.
I agree the UI makes you jump thru many useless hoops.
But it's the UI, not the config system itself.
Cheers
Andrea
Jody Garnett ha scritto:
Nice write up, not sure I can add much to framework discussion due to lack of experience. It is clear that Struts has run its course
Aside: Confluence is based on Webwork (or at least the velocity part of it), and I have not always found the hacking environment friendly.
A couple of priorities:
- internationalization, can we compare the frameworks in this respect as well
All frameworks I've looked at deal with internationalization well.
- WTP - using the web tools project right now, since most developers are on eclipse we may check what works well in this environment
JSP support we won't use, since we can't use JSPs to start with.
But plain XHTML editing is nice. I think a good solution should not ask
for more than that (i.e. if it requires more, the extra value should
compensate for the need for more complex tools as well...)
- workflow, have a look at a running "continnuum" this is about perfect for monitor and config application (I am very impressed)
We'll have a look at it, thank you.
Questions:
- What was the name of the internationalization JCP that was trying to replace the Struts + Tiles approach? Was that JSF?
Do you mean Shale? Anyways, standard JSF are out of question because they do use JSP, we could consider the "facelets" variant, that do use
pure XHTML templates (but still requires XML configuration files all
over the place, I want a solution based on "convention over configuration" instead).
And it should be pointed out that none of this really get's us out of making a JMX bean available to monitor the running GeoServer, and probably teach it about oracle connection pools as well.
Different concerns, we should not consider them now. JMX is a remoting
technology, not UI. Oracle connection pooling is a matter of datastore
configuration, the current UI could deal with it pretty easily, just
add a text field that refers to the connection pool JNDI name.
The User interface design was simple a page of "Downsides of the current UI", I have provided some content with an outline of a "cross bar navigation" approach.
What's a cross bar navigation approach? I just see a tree there?
Cheers
Andrea
On Wed, January 3, 2007 4:53 am, Andrea Aime wrote:
Jody Garnett ha scritto:
Catching up on email,
With respect to the "New configuration" I am really interested in
seeing the GeoTools catalog interfaces used this time around. They are
forth generation out from the geoserver original, provide an open ended
way to attach additional information for new services (ie NamedStyle or
SLD for
WMS) etc...They well may be part of the solution, but not a requirement I guess?
I wish I could understand them better, when I faced the uDig version I
simply gave up (the solution seemed to be way too complex for the problem
it tried to solve, but it may well be that uDig uses only a tiny fraction
of their expressive power). When we go down and design a solution, let's
see how they fit and what advantages they bring, it may well be that I get
to understand their value this timeThe page seems to focus on XML, I would actually like to see some
independence here - so the configuration can be stored in a database or
filesystem. Storing in a common database is one of the best ways to get
a clustering solution off the ground for example.Indeed, that's what I've stated on the last paragraph of that page too
To achieve real independence we would have to force developers to
provide enough metadata to allow each configuration component to be
serialized to different storages. XStream does not need extra info, JAXB
needs schemas, Hibernate needs mapping configuration files (since we're
stuck on jdk 1.4), and so on. Modularity and tech independence fight each
other, we should have a mandate that each new modules works at least with
one storage backend (asking people to make things work against multiple
ones is too much).That's why I insisted on XML and XStream, seems to be the least common
denominator and the easiest one to deal with, developer of new module
doesn't really need to understand any other technology, just needs java
beans. As some others pointed out, file storage has also the
interesting property of being usable as a layman tool for configuration
exchange (not for distributed network service things, I just think about
debugging issues, the kind of "give me your configuration so that I can
have a look at it"). Configuration is not something you can move from one
geoserver to the other anyways, since you're not moving the datastores as
well usually :-p (ok, you can move shapefiles, but not dbms ones as
easily).That said, yeah, the solution should be made so that you're insulated
from actual data storage, so if one needs a database backend it's easy to
write. Or, we could ask for database backend as normal storage (using hsql
or h2) as use XML just as a import/export tool.
Yeah, I like the thought of XML as the import/export format. And that's
why it makes sense for us to target it first. We should have good docs on
how to make a 'persistance class' that can backend to anything. But one
should always be able to import an XML file, or export it out for us to
have a look out. Ideally through the web-admin tool - indeed it'd be
great if GeoServer could track multiple configs somehow.
Chris
Ok, I'm updating the page trying to incorporate these considerations.
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,459b7e3d272291804284693!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
That said, yeah, the solution should be made so that you're insulated
from actual data storage, so if one needs a database backend it's easy to
write. Or, we could ask for database backend as normal storage (using hsql
or h2) as use XML just as a import/export tool.Yeah, I like the thought of XML as the import/export format. And that's
why it makes sense for us to target it first. We should have good docs on
how to make a 'persistance class' that can backend to anything. But one
should always be able to import an XML file, or export it out for us to
have a look out. Ideally through the web-admin tool - indeed it'd be
great if GeoServer could track multiple configs somehow.
Hum, multiple configs as in choosing one out of a list and run with it,
or as in virtual sub-server, each running its own?
http://myhost:8080/geoserver/config1/wfs?…
http://myhost:8080/geoserver/config2/wfs?…
The latter can be achieved by deploying multiple geoserver instances as
well, thought it may not be super-clean...
Cheers
Andrea