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

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 chan

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

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 create

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

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 completi

[Geoserver-devel] [jira] Created: (GEOS-1829) Spatial filters do not handle functions as second argument

Spatial filters do not handle functions as second argument -- Key: GEOS-1829 URL: http://jira.codehaus.org/browse/GEOS-1829 Project: GeoServer Issue Type: Bug Reporter: Just

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #12

See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/12/changes Changes: [jdeolive] GEOS-1682, removing stale jars for arcsde and mysql extensions -- [...truncated 77 lines...] [INFO] snapshot org.geotools:gt2-modules:2.5-SNAPSHOT: checking fo

Re: [Geoserver-devel] Transition from docs.codehaus.org to geoserver.org

Sorry, got lost in the shuffle. I've updated the GEOSDOC and GEOSDEV spaces to allow attachment uploads by registered users. Previously this was only true for GEOS. Let me know if there are more problems (feel free to CC me regarding Confluence issues, so my email client highlights them). -Arn

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

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 di

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

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 think

Re: [Geoserver-devel] Transition from docs.codehaus.org to geoserver.org

One of the main advantages of it on geoserver.org is that it's now much easier for us to change. So unless there was some weird upgrade to confluence that prevents that it should be easy for us to modify. Arne, could you look in to it? Tyler Erickson wrote: The permissions related to attach

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

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

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

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 la

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

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, o

Re: [Geoserver-devel] Transition from docs.codehaus.org to geoserver.org

The permissions related to attachments seem to be more restrictive on the geoserver.org wiki than they are on the docs.codehause.org wiki. On the geoserver.org wiki, I can see and 'edit' the attachments, but I cannot add any new attachments to any pages. Can this be changed? Chris Holmes wrote:

Re: [Geoserver-devel] GEOS-1815

Gabriel Roldán ha scritto: > On Tuesday 25 March 2008 06:35:07 pm Justin Deoliveira wrote: >> Hi Gabriel, >> >> I actually meant to assign this to myself... must have slipped. But if >> you want to take it by all means be my guest :). > np, it was cholmes choice. >> So yeah... I think I meant more

Re: [Geoserver-devel] GEOS-1815

On Tuesday 25 March 2008 06:35:07 pm Justin Deoliveira wrote: > Hi Gabriel, > > I actually meant to assign this to myself... must have slipped. But if > you want to take it by all means be my guest :). np, it was cholmes choice. > > So yeah... I think I meant more a), but b) is very much valid too.

Re: [Geoserver-devel] Releases

Chris Holmes ha scritto: > Hey all, so first I want to apologize for being opaque on the process of > when releases have been cut recently, not giving people a chance to get > their changes in before putting it out. > > We've now got Mike aboard to help us with the mechanical process of > cutti

Re: [Geoserver-devel] GEOS-1815

Hi Gabriel, I actually meant to assign this to myself... must have slipped. But if you want to take it by all means be my guest :). So yeah... I think I meant more a), but b) is very much valid too. Although I think the dispatcher may already ensure that b) is done. -Justin Gabriel Roldán wro

[Geoserver-devel] GEOS-1815

Hi Justin, about , I wonder if it means: a- ensuring the responses are encoded in the globally configured geoserver charset b- ensuring the http response header for the charset encoding is set or both. I guess both, as the issue does not tell just wante

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

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

Re: [Geoserver-devel] SLD not null filter

(This question is more appropriate for the users list, this is the developers list) As for your question. You should be able to pull this off with the following filter functions: foo true foo 0 Let us know if that works. -Justi

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

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

[Geoserver-devel] Releases

Hey all, so first I want to apologize for being opaque on the process of when releases have been cut recently, not giving people a chance to get their changes in before putting it out. We've now got Mike aboard to help us with the mechanical process of cutting releases, so I'm hoping that we c

[Geoserver-devel] [jira] Created: (GEOS-1828) Announcement items

Announcement items -- Key: GEOS-1828 URL: http://jira.codehaus.org/browse/GEOS-1828 Project: GeoServer Issue Type: Task Components: Documentation Reporter: Andrea Aime Assignee: Mike Pumphrey

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

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. >

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

> > 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 speci

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

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

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

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