I agree with Chris and Jonathon that this is not a major issue (if an issue at all). And of course yes deprecate something does not mean removing it.
Jacques ----- Message d'origine ----- De : "Jonathon -- Improov" <[EMAIL PROTECTED]> À : <[email protected]> Envoyé : jeudi 7 juin 2007 09:44 Objet : Re: Substring method for minilang? > > +1, but large work if we want to change all existing tag in code. > > I suggest we simply deprecate the attribute, and add a new one. > > And when do we remove the attribute? I don't know. To be lazy about it, never, until we need to > add a new attribute that happens to have the same name as the deprecated attribute. Ie, until we > need to actually remove the deprecated attribute to make way for a new one. > > Or until we have built a "migration tool" that automatically converts all tags to use the new > attribute. This isn't tough to do, just a matter of regexp replace work. > > Jonathon > > Jacques Le Roux wrote: > >> I really like Minilang too. > >> It's true that the syntax of each single operation is not concise, but > >> the end results, i.e. the whole methods/services, are incredibly > > compact. > >> And the best thing is that you write down a service in Minilang in the > >> same exact way as you describe it in English language. > >> However theree are a few areas where Minilang could be improved, in my > >> opinion: > >> > >> 1) consolidation of similar operations; for example <if>, <if-compare> > >> and <if-compare-field> could be probably unified to one (a similar > >> effort was done with the <set/> operation) > > > > +1, I get caught with this one yesterday :o) > > > > > >> 2) we should deprecate the usage of map-name attributes and use > > instead > >> the field="mapName.fieldName" syntax > > > > +1, but large work if we want to change all existing tag in code. > > > >> 3) the naming conventions for attributes is not always the same: for > >> example "field-name" and "field" (and sometimes "value-name" or > >> "env-name", even if I know they are slightly different concepts) are > >> used to reference similar objects in different operations; I'd prefer > > to > >> always use everywhere the "field" and "from-field"/"value" attributes > >> everywhere, foe example: > >> instead of <store-value value-name="product"/>, I'd prefer > > <store-value > >> field="product"/> > > > > +1 for the example at least > > > >> 4) math operations in Minilang are a bit complex to write/read: it > > would > >> be great to have something like "fieldA * (fieldB + fieldC) - 3.0" > > > > Did not use it much for now, but yes why not... > > > >> This is my wish list for this great tool that, together with > >> Menu/Screen/Form widgets, can greatly improve your efficiency in the > >> development/customization of OFBiz > > > > Yes totally agree about good productivity with this tools. For instance, > > yesterday I just added some fields in the ProdcutStore entity (in the > > right place for order of fields to not have to change the form using > > sort-order) and I was done, what can compete here ? ;o) > > > > Jacques > > > >> Jacopo > >> > >> > >> Jacques Le Roux wrote: > >>> It took me some time to got used to Minilang but now I really like > > it. > >>> Not having to deal with try/catch is one of the feature I like (will > >>> Groovy be able to do such thing ?). Be able to easily deal with the > >>> entity engine is really pleaseant too. Using an XML editor with > > syntax > >>> completion you do not have to type too much characters (and you can > >>> enjoy copy/paste as everywhere). > >>> > >>> Once you get acquainted to it, I believe Minilang is the right tool > > in > >>> the right place. > >>> > >>> This said, I agree that Groovy is for sure very interesting... > >>> > >>> Jacques > >>> > >>> PS : Jonathon has explained why he likes the map-processor. I agree, > > I > >>> just wonder if there is a way to use it the other way around when > > you > >>> copy fields from a map to another. Is there a way to copy all but > > some ? > >>> Sort of exclude tag. I wonder why this does not exist. I miss > > something > >>> here ? > >>> > >>> > >>>> On Wednesday 06 June 2007 10:51:28 pm David E Jones wrote: > >>>>> Alternatively Ean, and maybe even better: in an ideal world what > >>> would you > >>>>> use in place of the MiniLang/simple-method code (regardless of > >>> whether or > >>>>> not it exists already)? > >>>>> > >>>>> As we've done in the past, if there is anything that represents a > >>>>> sufficient efficiency gain for development and maintenance it may > >>> very well > >>>>> be worth the transition to it. > >>>> Wellll.... > >>>> > >>>> I don't like the XML approach because the code is difficult to read > >>> and it > >>>> makes me type a lot of characters that have no syntactic meaning > > when > >>> I > >>>> presume Minilang is intended to reduce typing. I also assume (or > > have > >>> heard) > >>>> that using XML simplifies parsing and generation so that a GUI > > based > >>> tool > >>>> could be built on top of it. I accept that idea but note that > > pretty > >>> much any > >>>> major language built on the Java VM generates some sort of the AST > > and > >>>> outputting that tree to an XML format would be pretty trivial. I > > also > >>> note > >>>> that we do not have such a case tool and wonder if we really want > > to > >>> duel > >>>> with something like BPEL (I vote no). > >>>> > >>>> I think that most of the scripting conveniences afforded by > > MiniLang > >>> can be > >>>> achieved more thoroughly by one of the many scripting languages > >>> available for > >>>> the JVM. My personal choice would be Groovy because it offers the > > same > >>>> conveniences touted by other dynamic languages and its Map > > syntactic > >>> sugar > >>>> directly supports native Java Maps. This feature should not be > >>> underestimated > >>>> because it is suprsingly absent from both Jython and JRuby and is > >>> very, very > >>>> useful: > >>>> > >>>> delegator.findByPrimaryKey("UserLogin", ["userLoginId": "admin"]) > >>>> person.firstName = "Ean" > >>>> address.putAll([address1: "1000 Smith St.", stateProvinceGeoId: > > "TX", > >>>> postalCode: "75226"]); > >>>> ...etc... > >>>> > >>>> More than once I've thought about XSLT that produces Groovy from > >>> Minilang. > >>>> Regex sugar, closures, dynamic typing and tree builders all are > >>> tremendous > >>>> conveniences. Operator overloading also implies certain guilty > >>> pleasures that > >>>> are best not discussed on this public list. Plus Groovy compiles to > >>> native > >>>> bytecode and is already supported by a JSR. > >>>> > >>>> Plus we'd get lots of marketing cheese out of a move like that. > >>>> > >>>> I also wonder if we shouldn't wrap the dispatcher in a proxy and do > >>> things > >>>> like: > >>>> > >>>> me = [:] > >>>> me.firstName = "Ean" > >>>> me.lastName = "Schuessler" > >>>> dispatcher.createPerson(me) > >>>> > >>>> That's my .02 anyway. > >>>> > >>>> -- > >>>> Ean Schuessler, CTO > >>>> [EMAIL PROTECTED] > >>>> 214-720-0700 x 315 > >>>> Brainfood, Inc. > >>>> http://www.brainfood.com > > > >
