Chris Holmes ha scritto:
> Arne and I are right now at:
>
> Choosing Your Java™ Technology-Based Web Framework: A Comparison
>
> https://www28.cplan.com/cc191/sessions_catalog.jsp?ilc=191-1&ilg=english&isort=&isort_type=&is=yes&icriteria9=TS-6457
>
Btw, I looked at the abstract and there is no
[EMAIL PROTECTED] ha scritto:
> So the talk wasn't enough to make any strong statements, but I was left
> with the impression that unless you want to Grails for the sake of
> Groovy, then there was little reason to consider anything but GWT or
> Wicket (ie. Tapestry and Struts 2 got grounded).
>
Geoserver returns an exception if a property-filter for a property of the type
string contains a letter, but in the db the property is of the type integer
---
Hi all,
still at it with new configuration work... and i have some questions
about CoverageStoreInfo, and how they relate to CoverageInfo, and
GridCoverageReader
I would think the relationship is similar as DataStoreInfo and
FeatureTypeInfo, one to many. However it seems that code that grabs a
So the talk wasn't enough to make any strong statements, but I was
left with the impression that unless you want to Grails for the sake
of Groovy, then there was little reason to consider anything but GWT
or Wicket (ie. Tapestry and Struts 2 got grounded).
I'm not the best person to ask, but
Just to chime in with my thoughts. Chris's suggestion of pure REST +
templating is quite tempting, just from a simplicity standpoint. easy to
understand how it works, low entry barrier, etc...
However in the end I think I agree with Andrea, an approach based on
this we will end up writing a lot
Luca Morandini wrote:
> Other frameworks too: hiding the UI rendering technology is a high on
> the list of many a tool (especially when client-side Javascript is
> involved).
>
> As I see it, the crux is whether UIs should be designed procedurally (as
> in wicket or GWT) or declaratively (as in
Arne and I are right now at:
Choosing Your Java™ Technology-Based Web Framework: A Comparison
https://www28.cplan.com/cc191/sessions_catalog.jsp?ilc=191-1&ilg=english&isort=&isort_type=&is=yes&icriteria9=TS-6457
So hopefully this will provide us with the answer at the end ;)
Andrea Aime wrote
Jody Garnett wrote:
> Luca Morandini wrote:
>> Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
>>
> I think you have hit the nail on the head; ie why we have been looking
> at use interface frameworks so carefully.
>
> There is a list of requirements Andrea was shoppin
Chris Holmes ha scritto:
> Ok, cool. Yeah, that was my fear with it, but then I saw that Hudson's
> user interface looked pretty nice. But it looks like you've already
> done a pretty full evaluation. Oh well, it was a nice dream to have for
> a bit :)
Eh, I was started the same way, I downl
Ok, cool. Yeah, that was my fear with it, but then I saw that Hudson's
user interface looked pretty nice. But it looks like you've already
done a pretty full evaluation. Oh well, it was a nice dream to have for
a bit :)
Chris
Andrea Aime wrote:
Chris Holmes ha scritto:
...
Ok, I don't w
Chris Holmes ha scritto:
...
> Ok, I don't want to dictate technology choices at all, since I won't
> be working with the codebase. But I do want REST as a first class
> citizen, in some ways even more so than the UI. So from my
> perspective it seems like having a technology that can handle bot
Andrea Aime wrote:
Chris Holmes ha scritto:
Apologies for not being all up on this thread, hopefully soon I'll
find some time to sit down and digest it all. But I wanted to throw
out a thought on UI.
Instead of picking a full blown UI framework we could consider just
using a template lang
Chris Holmes wrote:
> There obviously are some open questions in this approach, like what is
> lacking versus the full blown UI technologies - things like
> internationalization, ect. But I think we should do our UI technology
> evaluation hand in hand with our rest stuff.
I don't think I have
Chris Holmes ha scritto:
> Apologies for not being all up on this thread, hopefully soon I'll find
> some time to sit down and digest it all. But I wanted to throw out a
> thought on UI.
>
> Instead of picking a full blown UI framework we could consider just
> using a template language, like f
Apologies for not being all up on this thread, hopefully soon I'll find
some time to sit down and digest it all. But I wanted to throw out a
thought on UI.
Instead of picking a full blown UI framework we could consider just
using a template language, like freemarker, to provide the UI through
See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/214/changes
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use
Luca Morandini wrote:
> Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
>
I think you have hit the nail on the head; ie why we have been looking
at use interface frameworks so carefully.
There is a list of requirements Andrea was shopping for on a wiki page
somewhere,
So in Tuesday's meeting we figured out the scope for Geoserver 1.7,
renaming this subject line to match ...
Andrea Aime wrote:
> The "eat your own dog food" argument is good, but I expect the REST
> api to have its own battery of unit and functional tests (my position
> atm is to vote -1 for any c
See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/213/changes
Changes:
[aaime] GEOS-1904, Dump data loading stack traces with a normal logging
configuration, as it is now it makes error diagnosis just too hard
--
[...truncated 17 lines...]
Luca Morandini ha scritto:
> Andrea Aime wrote:
>> My plan was to tackle this by making the UI pluggable, but still pure
>> java.
>
> Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
Wicket is as pure java as it gets, you only have to write a (pure) html
file with ids an
Andrea Aime wrote:
>
> My plan was to tackle this by making the UI pluggable, but still pure
> java.
Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;)
> That is, each module has its own configuration UI module, if you
> don't want to use it, don't include its jar and yo
See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/212/changes
--
[...truncated 17 lines...]
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] GeoServer 1.6.x
[INFO] GeoServer Maven Plugins
[INFO] Plugins configuration
See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/211/changes
--
[...truncated 17 lines...]
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] GeoServer 1.6.x
[INFO] GeoServer Maven Plugins
[INFO] Plugins configuration
Saul Farber ha scritto:
> I agree with Luca on this one. I think "eating our own dog-food" is the
> surest and best way to properly develop and constantly test the REST
> api. Plus it puts all gui's on a level playing field.
>
> FlexJSON + the config back-end + REST for configuration would seem
25 matches
Mail list logo
