Can you assemble the good examples you found in to a page for the developers guide? -- Jody Garnett
On Thu, 9 May 2019 at 15:30, Chris Hodgson <[email protected]> wrote: > I agree, getting caught up in ideals and "perfection" prevents you from > moving forward with basic function. > > Also I know the source is really the ultimate developer documentation, and > any attempt at developer docs always gets stale. But as the code gets > bigger, it gets harder to find relevant examples. I went through all of the > other community modules and none of them were doing something like what I > was trying to do for MapML. > > The pointers to examples is exactly what I'm going for with the idea of > listing the extension points - if you at least have those names, you can > look for implementations, and you have a nice entry point into the code. I > was already aware of the output format extension points so those were > relatively easy to find and mimic. When I saw that the REST module was > using Spring MVC, and I've recently been building Spring MVC REST APIs, I > thought that's all I needed to know to be off and running. Apparently I > know just enough Spring to be dangerous ;) > > Anyways, just wondering if there is a way to turn my recent experience > with Geoserver development (as someone who has typically been more a user > of Geoserver as well as a GIS-oriented Java developer) into something > useful for those who follow (docs or otherwise). > > Chris > On 5/9/2019 6:11 AM, Andrea Aime wrote: > > Hi Chris, > thinking about this, I agree in part. It's true that it would be easier > if everything was more encapsulated, > I think we just have no idea how to get there, or maybe sometimes we do, > but it would take more time that > we have available. > > I'm not totally sold on the "we need everything documented" though, the > source code itself > is full of examples, I normally just go and see how things were done in > other places in the code > and mimic what I see. > > Maybe a starting point for docs would be just pointing out that plenty of > examples can be found looking > in the source code (e.g., scan the application context files for usages of > the same extension point, > look for the hierarchy of the extension point) and in tests. > An that GeoServer is an atypical Spring application, with lots of > historical baggage, > which means one should not assume what works for application of recent > writing should work for GeoServer, > and thus go and see what the existing and working code does instead. > > Cheers > Andrea > > > On Wed, May 8, 2019 at 8:03 PM Chris Hodgson <[email protected]> > wrote: > >> In fairness, it was actually the XML configuration that broke it >> (although it happened to be the XML configuration that specified >> allowing annotation-drive config). I'm not sure that the problem is >> really with where the configuration is, whether it is in an xml or a >> class annotation, the problem is that every module needs to be aware of >> what all other modules are doing so that they don't step on each other's >> toes. It is just a problem inherent to IoC that misbehaving modules can >> bring down the whole thing, particularly when there aren't enough >> controls in place. In this case, the whole Spring config door is wide >> open for a bad module author to abuse. >> >> In my case, I didn't realize that I was sharing the same spring mvc >> configuration as all the other geoserver modules, and I also didn't >> realize the entire effect of the spring config directive(s) that I was >> using. Then it was all compounded by my erroneous commit to include the >> module by default. >> >> I think the problem of every module needing to be aware of what all >> other modules are doing is improved somewhat by using a single XML >> config for module over annotations spread throughout the code because it >> is fewer places for other module authors to look. However, I think an >> even better solution is to reduce the need to be aware of what other >> modules are doing at all, with better encapsulation of each modules >> functions, and better documentation about what we do need to know about >> other modules. In this case it would be handy to know that that >> geoserver-rest module was basically replacing the entire spring MVC >> configuration system with its own mechanisms. Maybe a list somewhere in >> the geoserver docs of all extension points? Maybe I can contribute >> something to the docs about this, I see there is a placeholder there now. >> >> Chris >> >> On 5/6/2019 9:24 AM, Andrea Aime wrote: >> > Also, a bit of a rant if I can, these approaches based on annotations >> > look nice when coding them, but one never knows where >> > the side effects end up, while with XML hand wiring we get better >> > control (see also the mapml module breaking REST completely). >> > I guess we should try to discourage using annotations in a project as >> > large and complex as GeoServer? >> > >> > Cheers >> > Andrea >> > >> >> >> >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > -- > > Regards, Andrea Aime == GeoServer Professional Services from the experts! > Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime > @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 > Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 > 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > > -- > Chris Hodgson > Refractions Research > Suite 419 – 1207 Douglas Street > Victoria, British Columbia > Canada, V8W 2E7 > 1-250-383-3022http://www.refractions.net > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
