Thanks Andrea, I understand I am a bit late providing feedback.
With respect to events, perhaps the interface stability aspect is addressed
by the ability to add default methods.
And I agree the pattern is: RenderListener listens for RenderEvents which
may have a RenderEvent.Type (along with other state).
I do not feel strongly, only want the stability aspect considered.
--
Jody Garnett
On Thu, 17 Oct 2019 at 10:10, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Can I ask you to fill in the tasks section, want to be sure we have a
>> clear picture of the work involved.
>>
>> You have events for the layer by layer notifications, and subsequent
>> labeling activities, is there any need to have events for the composition
>> steps (thinking of the rendering into multiple buffers and resulting alpha
>> blending effects).
>>
>
> No need at the moment, but you can make your own GSIP for it if you do? :-)
> Generally speaking it's bad form to ask others for scope increase, but
> it's fundamental that we check
> the proposed design does not prevent those future improvements.
>
>
>> I tend to prefer notification with event enumerations, rather than
>> "labellingStart" and "labellingEnd" which does not scale.
>>
>> Would you consider something along the lines of:
>>
>> public interface RenderListener {
>> enum RenderEvent { START, UPDATE, END };
>> default void layer( Layer layer, RenderEvent event ); // covers
>> START, END
>> default void labeling( RenderingEvent event ); // covers START, END
>> default void composition( String name, RenderingEvent event ); //
>> covers START, UPDATE, END
>> default void rendering( RenderEvent event ); // covers START, END
>> }
>>
>
> Hum... does not really improve scalability IMHO, cuts in half the number
> of methods, does not make them a order of magnitude
> smaller or a fixed number. And things like "RenderEvent" are normally
> objects carrying around the "change" information in listener
> interfaces having a single listen method, rather than being a
> classification... If we go for this design I'd call them EventType instead.
> Given that there are default implementations, an implementor does not
> really have to work though them, if interested in a single
> even, they can implement just that method.
>
> My reaction to this is... meh... do you feel strongly about it? Not the
> biggest deal to change the implementation, but honestly
> I liked the interface as proposed better :-D
>
> Cheers
> Andrea
>
> == 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.*
>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
