[Geoserver-devel] New GeoServer UI frameworks requirements: feedback appreciated

[Andrea_Aime3]

Hi,
one year ago we tried to define a list of requirements and wishes
that a new UI framework should satisfy in order to be used for
the GeoServer UI remake. Analysys did not go so well, mainly because
at the time only one candidate (Wicket) was found satisfying all
requirement, and apparently there was not enough interest in redoing
the UI to invest on it.

One year has passed and a few things have changed. Moreover, some
of us believe that the June sprint could be a nice occasion to
switch the UI to a new framework, meaning that we need a decision
on what we're going to use.

Now, we can have a list of "requirements", but no framework will,
in general, satisfy them all. Also, not every developer will
feel the same about each item importance.
So what about coming up with a list of items, and then have
the developers that are really going to use the framework to do the UI
can do a vote?

Here is my list of wishes, sorted in order of importance, on the web
framework that we'll be using:
0) Open source
1) active, big community, very likely to be still around in the next
    5 years
2) supports internationalization
3) allows the development of a modular UI, that is, an UI
    where pages and components are located in the JARS, as opposed
    to being stored in a single place, the web application itself.
    This allows for new service UI to be plugged in, as well as
    datastore specific UI pages, or service specific extensions
    to the feature type configuration page (think of the current
    page, but with WFS,WMS,WPS tabs for the configuration elements
    that are relevant only to a specific service)
4) good documentation, either has top notch web documentation or
    a few up to date books on it
5) fast development, meaning tool support in Eclipse, good
    error reporting, fast development turnaround
6) easy to learn for a java developer. The main user for it will
    be a java developer that has to do some UI in order to expose
    the configuration, he won't be an HTML/javascript/XML wizard
7) compact, ideally would need just the definition of a template
    and a backing class to control its contents and navigation
8) possibly with a small payload in terms of jars to be
    included in GeoServer (GeoServer is at the moment around
    30MB, let's try to avoid jumping to 50)
9) possibly does not require JDK, but works with JRE instead
    (so that we can distribute an installer with everything
    included)
10) (very personal) with as less XML as possible around

Wondering, what are other people's ones?

One thing to notice is that requirement 3) is what kills most
of the web framework, in that it's impossible to attain, or
it's possible but makes development quite a bit harder.
Dropping it would open the gate to a wider list of
frameworks... what is other developer's opinion on it?
I cannot really think like dropping the requirement, since
I don't see how we could have a per datastore config page
or how could we allow the development of new custom services
outside of the geoserver code base. Yet I'm curious about
hearing other people opinions.

Cheers
Andrea

[Andrea_Aime3]

Andrea Aime ha scritto:

One thing to notice is that requirement 3) is what kills most
of the web framework, in that it's impossible to attain, or
it's possible but makes development quite a bit harder.
Dropping it would open the gate to a wider list of
frameworks... what is other developer's opinion on it?
I cannot really think like dropping the requirement, since
I don't see how we could have a per datastore config page
or how could we allow the development of new custom services
outside of the geoserver code base. Yet I'm curious about
hearing other people opinions.

It's interesting to see how Hudson does its own plugins:
http://weblogs.java.net/blog/kohsuke/archive/2006/08/hudson_140_and.html

It's a little sad to see that the author ended up using a view
technology that has no tool support, and created his
own web framework (https://stapler.dev.java.net/what-is.html), since he could not find anything that suited his way of doing things.

Cheers
Andrea

[Rob_Atkinson1]

Excellent analysis Andrea. I'd agree with all these points.

Couple of points to explore;

a) reusability of common components - things like file browsers etc
are often provided by the framework, but can we create additional
re-usable plugins easily - such as CRS choosers?

b) in the case of plug-in components, this is achieved by
configuration round a standard interaction model, or by implementation
against a lighter-weight API. Most XML based approaches are in reality
attempting to create an interaction model with data-driven
configuration - but I agree that XSLT starts to get tto much logic and
its instrinisically hard to modularise and reuse. Data stores
providing separate UIs or data to drive a common UI is an interesting
case in point. IMHO, most (if not all!) the metadata required to drive
a feature type configuration should be drawn from existing registries
- CRS, feature type, user who logged in, datastore connection (tested
by a stand-alone reusable configuration). This means a high level of
sophistication between the UI and the sources of data, and creating
many one-off per-datastore UIs is not going to cut it unless we have
an explicit strategy to create a good library of reusable building
blocks, or a good data-driven template.

There is always a trade-off between ease of development of a single
implementation and ease of use. Development of good quality re-usable
peices can ease development and improve usability. This is an
investment, but is probably how we should approach the problem: for
each UI function, we should ask ourselves if we are getting the info
from the optimal place in the optimal way, and is it a common problem?

RA

On Tue, Mar 25, 2008 at 6:45 AM, Andrea Aime <aaime@anonymised.com> wrote:

Andrea Aime ha scritto:

> One thing to notice is that requirement 3) is what kills most
> of the web framework, in that it's impossible to attain, or
> it's possible but makes development quite a bit harder.
> Dropping it would open the gate to a wider list of
> frameworks... what is other developer's opinion on it?
> I cannot really think like dropping the requirement, since
> I don't see how we could have a per datastore config page
> or how could we allow the development of new custom services
> outside of the geoserver code base. Yet I'm curious about
> hearing other people opinions.

It's interesting to see how Hudson does its own plugins:
http://weblogs.java.net/blog/kohsuke/archive/2006/08/hudson_140_and.html

It's a little sad to see that the author ended up using a view
technology that has no tool support, and created his
own web framework (https://stapler.dev.java.net/what-is.html), since he
could not find anything that suited his way of doing things.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Justin_Deoliveira]

Hi Andrea,

This is a pretty darn good list, it pretty much sums everything up. Just to add my 2 cents about requirement 3. One thing to consider that would allow us to relax this requirement, would instead make it extremely easy to build and redeploy a new UI. Which brings us perhaps to another requirement:

11) Decoupling the UI from the rest of GeoServer

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api. Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

Anyways, back to the original point. Having a ui component that is easy to build and deploy would allow developers to hack custom pages directly, and not have to rebuild and redeploy the entire server. This would probably be "good enough", and also relieve the requirement of a truly pluggable or modular UI.

My 2c.

-Justin

Andrea Aime wrote:

Hi,
one year ago we tried to define a list of requirements and wishes
that a new UI framework should satisfy in order to be used for
the GeoServer UI remake. Analysys did not go so well, mainly because
at the time only one candidate (Wicket) was found satisfying all
requirement, and apparently there was not enough interest in redoing
the UI to invest on it.

One year has passed and a few things have changed. Moreover, some
of us believe that the June sprint could be a nice occasion to
switch the UI to a new framework, meaning that we need a decision
on what we're going to use.

Now, we can have a list of "requirements", but no framework will,
in general, satisfy them all. Also, not every developer will
feel the same about each item importance.
So what about coming up with a list of items, and then have
the developers that are really going to use the framework to do the UI
can do a vote?

Here is my list of wishes, sorted in order of importance, on the web
framework that we'll be using:
0) Open source
1) active, big community, very likely to be still around in the next
    5 years
2) supports internationalization
3) allows the development of a modular UI, that is, an UI
    where pages and components are located in the JARS, as opposed
    to being stored in a single place, the web application itself.
    This allows for new service UI to be plugged in, as well as
    datastore specific UI pages, or service specific extensions
    to the feature type configuration page (think of the current
    page, but with WFS,WMS,WPS tabs for the configuration elements
    that are relevant only to a specific service)
4) good documentation, either has top notch web documentation or
    a few up to date books on it
5) fast development, meaning tool support in Eclipse, good
    error reporting, fast development turnaround
6) easy to learn for a java developer. The main user for it will
    be a java developer that has to do some UI in order to expose
    the configuration, he won't be an HTML/javascript/XML wizard
7) compact, ideally would need just the definition of a template
    and a backing class to control its contents and navigation
8) possibly with a small payload in terms of jars to be
    included in GeoServer (GeoServer is at the moment around
    30MB, let's try to avoid jumping to 50)
9) possibly does not require JDK, but works with JRE instead
    (so that we can distribute an installer with everything
    included)
10) (very personal) with as less XML as possible around

Wondering, what are other people's ones?

One thing to notice is that requirement 3) is what kills most
of the web framework, in that it's impossible to attain, or
it's possible but makes development quite a bit harder.
Dropping it would open the gate to a wider list of
frameworks... what is other developer's opinion on it?
I cannot really think like dropping the requirement, since
I don't see how we could have a per datastore config page
or how could we allow the development of new custom services
outside of the geoserver code base. Yet I'm curious about
hearing other people opinions.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47e7e0ce190951628642973!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Hi Andrea,

This is a pretty darn good list, it pretty much sums everything up. Just to add my 2 cents about requirement 3. One thing to consider that would allow us to relax this requirement, would instead make it extremely easy to build and redeploy a new UI. Which brings us perhaps to another requirement:

11) Decoupling the UI from the rest of GeoServer

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api.

Which may delay one more time the creation of the new UI, since today we
have no such a thing as a good REST api (afaik we have a sort of working
prototype? Haven't really checked it). Does TOPP think of investing
on it enough to have a usable one by the June code sprint?

Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

I already have heard someone asking why we need an UI at all. This kind of user loves to alter by hand the configuration files, so does not really need a UI. Yet, this kind of user needs good documentation on
the file formats, and some stability guarantee, we haven't been able to
provide either so far.

(personally, if I was a user and GeoServer did not have a configuration UI, I would not even bother to download it, so I represent the opposite kind user, the one that does not really bothers about configuration
files and screams aloud every time he has to make a new SLD).

Anyways, back to the original point. Having a ui component that is easy to build and deploy would allow developers to hack custom pages directly, and not have to rebuild and redeploy the entire server. This would probably be "good enough", and also relieve the requirement of a truly pluggable or modular UI.

Hum, so you're proposing a UI made in some scripting language, such
as pure javascript or Groovy/Grails? Imho this would either:
* require dedicated UI people or
* raise the bar on the GeoServer developer, asking him to be a very
   proficient java developer (otherwise he won't be able to do anything
   with the gt2/gs API) and a good enough scripting language developer.

Both options scare me a little. Just yesterday I stopped working on
struts2 out of frustration because there is no tool support for
developing HTML pages with embedded freemarker directives and
struts2 tags (tool support == code completion, I'm not asking
for auto-documentation or refactoring).
How people can develop code without code completion
support these days is really beyond my comprehension
Ok, end of rant. Just my opinion, if other people feel like going
down this road I'll endure the pain and try to adjust.

What other people think of the scripting option?
Or did I misunderstood it completely and you're thinking of something else?
Cheers
Andrea

[Andrea_Aime3]

Rob Atkinson ha scritto:

Excellent analysis Andrea. I'd agree with all these points.

Couple of points to explore;

a) reusability of common components - things like file browsers etc
are often provided by the framework, but can we create additional
re-usable plugins easily - such as CRS choosers?

I think it's possible. Both wicket, gwt and pure javascript solutions
like extj have the concept of a component. Struts2 has the concept of tag, which may be a table, a tree or the like, so I guess custom ones
could be developed to have a file browser or a crs chooser.

b) in the case of plug-in components, this is achieved by
configuration round a standard interaction model, or by implementation
against a lighter-weight API. Most XML based approaches are in reality
attempting to create an interaction model with data-driven
configuration - but I agree that XSLT starts to get tto much logic and
its instrinisically hard to modularise and reuse. Data stores
providing separate UIs or data to drive a common UI is an interesting
case in point. IMHO, most (if not all!) the metadata required to drive
a feature type configuration should be drawn from existing registries
- CRS, feature type, user who logged in, datastore connection (tested
by a stand-alone reusable configuration). This means a high level of
sophistication between the UI and the sources of data, and creating
many one-off per-datastore UIs is not going to cut it unless we have
an explicit strategy to create a good library of reusable building
blocks, or a good data-driven template.

I'm not sure I'm understanding 50% of what you're saying, but in my
experience metadata driven UI (like the one we have now) tend to be
very poor substitutes for hand crafted ones. In order to get close
enough to a usable UI you have to specify so much metadata that you
can probably do a custom programmed one with less effort and without
having to know about a new XML soup required to provide the necessary
information.

There is always a trade-off between ease of development of a single
implementation and ease of use. Development of good quality re-usable
peices can ease development and improve usability. This is an
investment, but is probably how we should approach the problem: for
each UI function, we should ask ourselves if we are getting the info
from the optimal place in the optimal way, and is it a common problem?

Can you make me an example of "getting the info from the optimal place
in the optimal way"? Afaik with the current configuration API we have
just one place to grab each information we need to build up a UI,
and this sounds like a very good thing (TM) imho.

Cheers
Andrea

[Rob_Atkinson1]

Can you make me an example of "getting the info from the optimal place
in the optimal way"? Afaik with the current configuration API we have
just one place to grab each information we need to build up a UI,
and this sounds like a very good thing (TM) imho.

OK, for example, we specify namespaces in several locations (schema,
info, datastore config, catalog file, SLD), but they should all be
inherited from the target schema (yes I know I'm talking about
community schema support, but there is very little requirement for WFS
without it - do you see many deployed?)

likewise, any filter or attribute controlled style in an SLD refers to
the schema.

We should put database connection params in one spot, not in each feature type.

all the "service metadata" probably ought to be derived from the
deploying organisations policies, and be linked to metadata in
something like GeoNetwork, not retyped.

etc

I see very little metadata or configuration that a deployer ought to
"make up" as they configure.

(but then again, my background is in building clients to use these
services, and registries and metadata to describe them - so i'm
convinced its more important to make it meaningful for the many users
than the few deployers or very few developers.)

Rob

Cheers
Andrea

[Andrea_Aime3]

Rob Atkinson ha scritto:

Can you make me an example of "getting the info from the optimal place
in the optimal way"? Afaik with the current configuration API we have
just one place to grab each information we need to build up a UI,
and this sounds like a very good thing (TM) imho.

OK, for example, we specify namespaces in several locations (schema,
info, datastore config, catalog file, SLD), but they should all be
inherited from the target schema (yes I know I'm talking about
community schema support, but there is very little requirement for WFS
without it - do you see many deployed?)

In production? Tens for sure, probably more.
Community schema is a nice to have, but lack of it did not stop
people from deploying WFS server all around the world.

Why do you have to put community schema as a requirement for everything
that has to be done in GeoServer is frankly beyond my comprehension.

I won't discuss this any further, since this is about feature type configuration, not about the UI framework.

Cheers
Andrea

[Justin_Deoliveira]

Hi Andrea,

I think you misinterpreted my comments :). I was not saying that we should not ship a UI in favor of a REST api, I was simply saying that with a good REST api, the UI becomes less of a necessity.

As for technology choice, you are putting words in my mouth :). I was not suggesting we commit to a UI based on a scripting language. Just that a decoupled UI would give us the ability to have a UI written in a "standard" java ui framework (like struts2), while at the same time allowing someone else to rip that out and replace with a different technology. Perhaps not useful enough to be a requirement.

Let me phrase this requirement another way. "Having the ability to take the UI jars away and still have GeoServer run."

I agree with you that forcing a UI built entirely in a scripting language is probably a bad idea. (Although I am not yet convinced we should rule out groovy/grails). However at some point you are going to need some client side scripting so you cant run from it altogether.

Regardless, I would prefer we put off any discussion about technology choice until we actually do the technology evaluation.

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

This is a pretty darn good list, it pretty much sums everything up. Just to add my 2 cents about requirement 3. One thing to consider that would allow us to relax this requirement, would instead make it extremely easy to build and redeploy a new UI. Which brings us perhaps to another requirement:

11) Decoupling the UI from the rest of GeoServer

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api.

Which may delay one more time the creation of the new UI, since today we
have no such a thing as a good REST api (afaik we have a sort of working
prototype? Haven't really checked it). Does TOPP think of investing
on it enough to have a usable one by the June code sprint?

Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

I already have heard someone asking why we need an UI at all. This kind of user loves to alter by hand the configuration files, so does not really need a UI. Yet, this kind of user needs good documentation on
the file formats, and some stability guarantee, we haven't been able to
provide either so far.

(personally, if I was a user and GeoServer did not have a configuration UI, I would not even bother to download it, so I represent the opposite kind user, the one that does not really bothers about configuration
files and screams aloud every time he has to make a new SLD).

Anyways, back to the original point. Having a ui component that is easy to build and deploy would allow developers to hack custom pages directly, and not have to rebuild and redeploy the entire server. This would probably be "good enough", and also relieve the requirement of a truly pluggable or modular UI.

Hum, so you're proposing a UI made in some scripting language, such
as pure javascript or Groovy/Grails? Imho this would either:
* require dedicated UI people or
* raise the bar on the GeoServer developer, asking him to be a very
  proficient java developer (otherwise he won't be able to do anything
  with the gt2/gs API) and a good enough scripting language developer.

Both options scare me a little. Just yesterday I stopped working on
struts2 out of frustration because there is no tool support for
developing HTML pages with embedded freemarker directives and
struts2 tags (tool support == code completion, I'm not asking
for auto-documentation or refactoring).
How people can develop code without code completion
support these days is really beyond my comprehension
Ok, end of rant. Just my opinion, if other people feel like going
down this road I'll endure the pain and try to adjust.

What other people think of the scripting option?
Or did I misunderstood it completely and you're thinking of something else?
Cheers
Andrea

!DSPAM:4007,47e8be72176153362379201!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Hi Andrea,

I think you misinterpreted my comments :). I was not saying that we should not ship a UI in favor of a REST api, I was simply saying that with a good REST api, the UI becomes less of a necessity.

I understood that. I'm just thinking the UI as a necessity and the
REST api as a nice to have (in my mind the first is what makes you
want to try out GeoServer, whilst the latter is something needed
for advanced usage only).

As for technology choice, you are putting words in my mouth :). I was not suggesting we commit to a UI based on a scripting language. Just that a decoupled UI would give us the ability to have a UI written in a "standard" java ui framework (like struts2), while at the same time allowing someone else to rip that out and replace with a different technology. Perhaps not useful enough to be a requirement.

I was not my intention to put words in your mouth, I was just trying
to understand
The thing is, if you make a new service, how do you make a new UI for it? If we roll a monolithic UI, you have to modify that module directly,
unless the UI is written in a scripting language, in that case you
may be able to tell people "just drop those scripts in the web module
and boom you'll have service XYZ UI". That's why I spoke of scripting
languages.

Let me phrase this requirement another way. "Having the ability to take the UI jars away and still have GeoServer run."

I agree with you that forcing a UI built entirely in a scripting language is probably a bad idea. (Although I am not yet convinced we should rule out groovy/grails). However at some point you are going to need some client side scripting so you cant run from it altogether.

Regardless, I would prefer we put off any discussion about technology choice until we actually do the technology evaluation.

Yes, me too. I was just trying to lay out an eventual extra requirement.
If none of the developers feel like using a scripting language, there
no point in evaluating one. If on the contrary I'm the only one that
feels against them, we should evaluate at least one (and someone other
than me has to make that evaluation since I'm evidently too biased
against them).
Cheers
Andrea

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Let me phrase this requirement another way. "Having the ability to take the UI jars away and still have GeoServer run."

Forgot to comment about this one. This seems orthogonal to having
the UI be modular, that is, you can have a single separated
monolithic UI, or have a WFS-UI jar, a WMS-UI jar and so on.

Let's say that having it really modular allows to dispose of the
UI without the need to code it as a separate web application,
whilst a monolithic, non pluggable UI would have to be
developed as a separate web app that talks to the geoserver
core using the REST api.

Cheers
Andrea

[jive]

Refractions recently reviewed a bunch of frameworks internally for AJAX work:
- Wicket - a really strong design that still allows a separation of code from html
- GWT - the joys of a magic AJAX compiler

Our evaluation was more towards the ability to do AJAX without having to keep up with the latest browser / Javascript changes. Both of the above were acceptable ( a lot of other things like Struts 2, raw Spring, etc... were rejected). I think the team ended up going with GWT based on previous experience.

Jody

[Chris_Holmes1]

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

This is a pretty darn good list, it pretty much sums everything up. Just to add my 2 cents about requirement 3. One thing to consider that would allow us to relax this requirement, would instead make it extremely easy to build and redeploy a new UI. Which brings us perhaps to another requirement:

11) Decoupling the UI from the rest of GeoServer

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api.

Which may delay one more time the creation of the new UI, since today we
have no such a thing as a good REST api (afaik we have a sort of working
prototype? Haven't really checked it). Does TOPP think of investing
on it enough to have a usable one by the June code sprint?

The prototype is working pretty decently. I do think it's a possibility that we would invest enough to have it usable by the code sprint, or soon after.

A good REST API is actually my one major new requirement since the last UI evaluation. Though I realize that the rest api can easily be decoupled from the UI conversation, I think rest support in the UI framework is one of my most important evaluation criteria. Or at least to evaluate REST support and UI at the same time. One of the goals of new configuration classes and new UI is to reduce the number of classes one has to touch to add a new feature to GeoServer. If the UI framework easily supports rest as a view of sorts then it could potentially be no more additional work to add a new option to the rest api. If the UI and rest framework are completely separate then that's another class that one needs to touch to get an option 'fully' in GeoServer.

I would like to see the most common configuration tasks be handled in an openlayers/ext based application, like uploading data and styling and the like. These should just use the rest api. We still need the full geoserver configuration UI, but I think it's not crazy to think that we can handle a lot of the basic configuration through the map. See my blog post at http://cholmes.wordpress.com/2008/03/05/letting-everyone-remix-web-maps/ Then the GeoServer UI is more an option for 'advanced' users, who want to tweak a lot more.

If we end up with a UI framework like wicket combined with a completely separate REST API like Restlet that can be fine, but if something like Struts 2 can handle much of the REST calls with a plug-in then that might make less overall code, so it'd be easier for contributors to get their heads around it.

Chris

Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

I already have heard someone asking why we need an UI at all. This kind of user loves to alter by hand the configuration files, so does not really need a UI. Yet, this kind of user needs good documentation on
the file formats, and some stability guarantee, we haven't been able to
provide either so far.

(personally, if I was a user and GeoServer did not have a configuration UI, I would not even bother to download it, so I represent the opposite kind user, the one that does not really bothers about configuration
files and screams aloud every time he has to make a new SLD).

Anyways, back to the original point. Having a ui component that is easy to build and deploy would allow developers to hack custom pages directly, and not have to rebuild and redeploy the entire server. This would probably be "good enough", and also relieve the requirement of a truly pluggable or modular UI.

Hum, so you're proposing a UI made in some scripting language, such
as pure javascript or Groovy/Grails? Imho this would either:
* require dedicated UI people or
* raise the bar on the GeoServer developer, asking him to be a very
   proficient java developer (otherwise he won't be able to do anything
   with the gt2/gs API) and a good enough scripting language developer.

Both options scare me a little. Just yesterday I stopped working on
struts2 out of frustration because there is no tool support for
developing HTML pages with embedded freemarker directives and
struts2 tags (tool support == code completion, I'm not asking
for auto-documentation or refactoring).
How people can develop code without code completion
support these days is really beyond my comprehension
Ok, end of rant. Just my opinion, if other people feel like going
down this road I'll endure the pain and try to adjust.

What other people think of the scripting option?
Or did I misunderstood it completely and you're thinking of something else?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,47e8be85176341137850744!

[Chris_Holmes1]

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

I think you misinterpreted my comments :). I was not saying that we should not ship a UI in favor of a REST api, I was simply saying that with a good REST api, the UI becomes less of a necessity.

I understood that. I'm just thinking the UI as a necessity and the
REST api as a nice to have (in my mind the first is what makes you
want to try out GeoServer, whilst the latter is something needed
for advanced usage only).

Sorry, I missed this before I wrote my email. From my perspective a REST configuration API is just about required. It's great for advanced users, and is great for javascript hooks to experiment with other UIs, as well as to script configuration from other languages. To be a modern internet application I'd say it's just about required. I'd be open to pushing on it just after we finish the UI up, or to do it in conjunction, but it's not something I want to wait much longer on. And we have been making good progress on it already.

best regards,

Chris

[Ben_Caradoc-Davies]

Andrea Aime wrote:

Community schema is a nice to have, but lack of it did not stop
people from deploying WFS server all around the world.
Why do you have to put community schema as a requirement for everything
that has to be done in GeoServer is frankly beyond my comprehension.
I won't discuss this any further, since this is about feature type configuration, not about the UI framework.

Community schema support directly impacts the choice of UI framework
because editing a complex feature data-store-to-feature-type mapping is
a complicated process. (Probably much more complicated than any other
configuration supported by GeoServer.)

One of the decisions in the choice of a UI framework is whether it can
readily support the manipulation of complex data stores. In my (albeit
limited) experience, I have found that complex feature mappings can be
deeply nested, and require detailed type binding. This suggests that a
UI to manipulate them will have to be rather sophisticated, perhaps
ruling out web-based front ends.

So why support complex features at all? GeoServer is no doubt a handy
tool for converting database queries into simple XML, but until the
generated XML can be mapped to conform to community schemas,
interoperability will be limited. Perhaps this is a niche goal at the
moment, but I suspect that the future benefits will substantial.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Luca_Morandini2]

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Both options scare me a little. Just yesterday I stopped working on
struts2 out of frustration because there is no tool support for
developing HTML pages with embedded freemarker directives and
struts2 tags (tool support == code completion, I'm not asking
for auto-documentation or refactoring).
How people can develop code without code completion
support these days is really beyond my comprehension

Hmm... every XML document with a schema has code completion, given a
decent XML editor.

Regards,

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

[Luca_Morandini2]

Justin Deoliveira wrote:

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api. Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

I'm not a GeoServer committer, but I cannot help giving my 2(euro)c:

I think an admin UI should be sort of on afterthought, even a separate
webapp.
Let's face it: UI are intrinsically volatile and diverse (AJAX,
Accessible i.e. non-Javascript, CLI, etc.), while the underlaying
(RESTful?) API is much more stable (if well-designed, that is).
That would be akin to CMSes, which use to separate repository from the
front-end.

So, my idea would be to first build the API, then (or concurrently) the
admin UI.
This would have a couple benefits:
1) Helping the developer adding a new service to focus on the API, not
the UI, possibly resulting in a better API.
2) Decreasing the GeoServer footprint in production environment, by
dropping the UI baggage (and increasing security).

Of course, this may cause a different pace of development of services
code and UI code, but there would always be the option of using Ant (or
even wget) to use a newly-added service API in a CLI fashion.

Anyways, back to the original point. Having a ui component that is easy to build and deploy would allow developers to hack custom pages directly, and not have to rebuild and redeploy the entire server. This would probably be "good enough", and also relieve the requirement of a truly pluggable or modular UI.

You mean, like dropping new pages/forms under some directory and being "good to go" ?

Regards,

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

[Luca_Morandini2]

Andrea Aime wrote:

Andrea Aime ha scritto:

It's interesting to see how Hudson does its own plugins:
http://weblogs.java.net/blog/kohsuke/archive/2006/08/hudson_140_and.html

It's a little sad to see that the author ended up using a view
technology that has no tool support, and created his
own web framework (https://stapler.dev.java.net/what-is.html), since he could not find anything that suited his way of doing things.

Well, I don't want to sound harsh, but I find a even more sad to rely on JSP and servlets: let me start from kohsuke's use case...
<<Even in the web app it's pretty convenient to overload views --- you'd
want to show a different page for displaying book details and CD
details. So depending on the kind of product 513, you'd want to use
different JSPs.
<snip/>
Once you get a "primary key", you still have to get to the
corresponding data from JSP, and when you have multiple JSPs that work
on the same data (perhaps you have createProduct.jsp and
checkProductInventory.jsp or something), then the said logic needs to be
on all such JSPs>>
...and let me show how this could be done in done in Cocoon (just off
the top of my head, apologies for syntax errors):

A bit of URI matching (NOTE: "{1}" returns the value of first "*"
wildcard character contained in the matched-URI's template):
<match template="product/*">
  <call function="showProduct">
    <parameter name="productId" value="{1}"/>
  </call>
</match>

<match template="product-*.html">
  <generate type="jx" src="product-detail-pages/product-{1}.jx">
  <serialize>
</match>

(NOTE: let's suppose details-cd.jx creates an HTML page for a CD, while
detail-book.jx creates one for a book).

A bit of Flowscript (essentially server-side Javascript, though Java may
be used as well):
import com.mycompany.inventory.Product;
function showProduct() {
  var prod= Product.getById(cocoon.parameters.productId);
  cocoon.sendPage("product-" + prod.getTypeName() + ".html",
      {product : prod}):
}

(NOTE: let's suppose the Product Java class implements the business of getting
a product out of the database given its id).

The page flow goes on like this:
1) The user requests the "product/513" URI.
2) The requested URI is matched by the first match and routed to the
showProduct() Flowscript function along with the productId parameter
(which is contained the last part of the URI, RESTful-style).
3) The showProduct() function collects the product's data and requests a
page depending on the type of the product (passing the product bean along).
4) The requested "product-cd.html" (or "product-book.html") URI is
matched by the second match and a product type-specific HTML page is
produced (via JX, a simple template languages) getting data from the
given product bean.

You may clearly see the different layers of the application:
1) URI matching and template pages: View.
2) Flowscript (Javascript or Java): Controller
3) POJOs (like Product): Model.

Better than Stapler and JSP, isn't it ? No coupling between files on
disk and URIs, clear separation between pages and actions.

Regards,

P.S.
Actually, if the matter is only about matching Java Classes to URIs and
doing some CRUD, I think RESTlet may be even more helpful.

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

[Andrea_Aime3]

Chris Holmes ha scritto:
...

If we end up with a UI framework like wicket combined with a completely separate REST API like Restlet that can be fine, but if something like Struts 2 can handle much of the REST calls with a plug-in then that might make less overall code, so it'd be easier for contributors to get their heads around it.

The only web frameworks that can do both UI and REST calls are the
action based ones, in a component based one (Wicket, JSF) web services
have nothing to do with UI building, whilst in an action based one
you're throwing out a document in response to a call so they can
be coaxed to do REST as well.
The only framework I know about that can do both UI and REST
is, as you stated, Struts2, with this plugin: http://struts.apache.org/2.x/docs/rest-plugin.html.

So if this is a strong requirement, then the UI evaluation is
pretty much done, we're left with just one candidate (or maybe
two? can Cocoon do both UI and REST api? can it emit json?).

Another thing that I was thinking about is the point that Arne
raised during yesterday's meeting about the current UI looking
bad and being clearly designed by a Java programmer as opposed
by an interaction designer.
An UI that does both REST and web pages has to behave like a
service framework anyways, so I guess this leaves no room at
all for an interaction designed to impose a different UI
workflow? This seems to me like something requiring the REST
API to be separated from the UI?
Again, how much do we value the ability to make a very good
UI as opposed to make it just a reflection of a good designed
REST api? Do you think both can be achieved at the same time?

One final thing that comes to mind is a reaction to the following
statement:
> The prototype is working pretty decently. I do think it's a possibility
> that we would invest enough to have it usable by the code sprint, or
> soon after.

Does it make sense to invest on it while considering the idea
of throwing it away and redoing it with a web framework that can
do REST as well?
Cheers
Andrea

[Andrea_Aime3]

Luca Morandini ha scritto:

Justin Deoliveira wrote:

I can see a couple of benefits. It could possibly reduce the download size if we wanted to release the webapp separately. Which may be something to consider once we have a good REST api. Or perhaps users who have a set data directory which does not really change do not have a need for the UI? I would be interested in hearing feedback on this one.

I'm not a GeoServer committer, but I cannot help giving my 2(euro)c:

I think an admin UI should be sort of on afterthought, even a separate
webapp.
Let's face it: UI are intrinsically volatile and diverse (AJAX,
Accessible i.e. non-Javascript, CLI, etc.), while the underlaying
(RESTful?) API is much more stable (if well-designed, that is).

I'm not sure about the stableness, at least for the next year to come.
The REST API gives you access to the underlaying configuration. Now,
for the past 1.5 years we've been delaying all non sponsored configuration changes because it was too painful to make them.
This means we piled up a lot of them.
When a more usable UI and a more usable configuration are in place,
we'll have to start addressing all of those complaints and start making
available all those extra control knobs we refused to add, meaning
that for quite some time the REST api outputs will be very unstable
(the overall architecture of the REST API may not change much, but the
documents returned and required for updates will change a lot imho).

That would be akin to CMSes, which use to separate repository from the
front-end.

So, my idea would be to first build the API, then (or concurrently) the
admin UI.
This would have a couple benefits:
1) Helping the developer adding a new service to focus on the API, not
the UI, possibly resulting in a better API.
2) Decreasing the GeoServer footprint in production environment, by
dropping the UI baggage (and increasing security).

This idea of making the UI a separate web application worries me.
So far we've tried to be the champions of the "easy to use", at least
for the first step, the getting started ones.
Having to deploy a separate application to configure GeoServer seems
to go in the opposite direction?

Of course, this may cause a different pace of development of services
code and UI code, but there would always be the option of using Ant (or
even wget) to use a newly-added service API in a CLI fashion.

Which is exactly what I wish to avoid, a situation where you have to
use non friendly tools because developers did not have time to develop
a usable UI (which is already happening btw with sld and freemarker templates, I find both of them very painful to work with and a major
shortcoming of the current GeoServer value proposition).

Cheers
Andrea