From: Nuno O. <nun...@te...> - 2015-07-09 12:53:29
|
Hi, I made a bad decision representing the dasharray property as an unique expression. Having the dasharray property represented as a set of expressions allows us to handle more uses cases and is more natural. It also helps solving the rescaling cases ... Thanks for the feedback. I will work on this. Best regards, Nuno Oliveira Le mardi 07 juillet 2015 à 00:34 +0100, Jody Garnett a écrit : > Yep. > > > I think we may map Label to several expressions, or perhaps it is a > single concatenate expression which is a variable argument function. > > > Actually if you want to follow that line of reasoning you could make > an function to evaluate > a list of expressions into a double[] - and then the parser / encoder > keep an eye out for that function. > > > Have a look at how label is parsed in anycase - it is a similar > problem. > > -- > Jody Garnett > > On 6 July 2015 at 15:00, Nuno Oliveira > <nun...@te...> wrote: > Hi, > > > The principle is not exactly the same as linecap and > linejoin are single values, while a dasharray is an array of > values. > > You're right my bad ... > > > I believe that's why Jody was expecting a Expression[], one > expression for each float/double value to be returned. > > This is more in line with the existing API than assuming a > single string that then needs to be tokenized > > using the comma as a separator. > > I assumed that an SLD property should always be mapped to a > single expression. So should I consider that a dash-array > property could be mapped to several expressions ? > > Best regards, > > Nuno Oliveira > > Le dimanche 05 juillet 2015 à 09:38 +0100, Andrea Aime a > écrit : > > On Fri, Jul 3, 2015 at 8:51 PM, Nuno Oliveira > > <nun...@te...> wrote: > > Thanks for your feedback. > > > > I'm a bit lost about his one .... > > > > I follow the same principie of others methods in > that class, > > for example: > > > > public static String lineLinecap(LineSymbolizer > > symbolizer) ... > > public static String lineLinejoin(LineSymbolizer > > symbolizer) ... > > > > > > The principle is not exactly the same as linecap and > linejoin are > > single values, > > while a dasharray is an array of values. > > I believe that's why Jody was expecting a Expression[], one > expression > > for > > each float/double value to be returned. This is more in line > with the > > existing > > API than assuming a single string that then needs to be > tokenized > > using the comma > > as a separator > > > > > > 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 Poggio alle Viti 1187 > > 55054 Massarosa (LU) > > Italy > > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > > > > > http://www.geo-solutions.it > > http://twitter.com/geosolutions_it > > > > > > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 > > > > Le informazioni contenute in questo messaggio di posta > elettronica e/o > > nel/i file/s allegato/i sono da considerarsi strettamente > riservate. > > Il loro utilizzo è consentito esclusivamente al destinatario > del > > messaggio, per le finalità indicate nel messaggio stesso. > Qualora > > riceviate questo messaggio senza esserne il destinatario, Vi > preghiamo > > cortesemente di darcene notizia via e-mail e di procedere > alla > > distruzione del messaggio stesso, cancellandolo dal Vostro > sistema. > > Conservare il messaggio stesso, divulgarlo anche in parte, > > distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per > finalità > > diverse, costituisce comportamento contrario ai principi > dettati dal > > D.Lgs. 196/2003. > > > > > > > > The information in this message and/or attachments, is > intended solely > > for the attention and use of the named addressee(s) and may > be > > confidential or proprietary in nature or covered by the > provisions of > > privacy act (Legislative Decree June, 30 2003, no.196 - > Italy's New > > Data Protection Code).Any use not in accord with its > purpose, any > > disclosure, reproduction, copying, distribution, or either > > dissemination, either whole or partial, is strictly > forbidden except > > previous formal approval of the named addressee(s). If you > are not the > > intended recipient, please contact immediately the sender by > > telephone, fax or e-mail and delete the information in this > message > > that has been received in error. The sender does not give > any warranty > > or accept liability as the content, accuracy or completeness > of sent > > messages and accepts no responsibility for changes made > after they > > were sent or for other risks which arise as a result of > e-mail > > transmission, viruses, etc. > > > > > > > > > > ------------------------------------------------------- > > > > > > |