Aaron, I never found a way to remove the warning "Unable to verify operator sum.periodes.count" for these except by writing a method that do the same:
<wo:if condition = "[email protected]" negate = "YES"> <wo:string value = "[email protected]" numberformat = "0.00"/> Is there a known way to tell the validator to remove the warning for the aggregation operators? Samuel Le 2014-03-25 à 23:23, Aaron Rosenzweig <[email protected]> a écrit : > Hi Christoph, > > “valid” works with inline bindings and you can wrap inline bindings across > newlines too. > > Here’s an example: > > <wo:popUpButton > list = "$allNamespaces” > item="$namespaceItem” > displayString="$namespaceItem.displayName” > noSelectionString="Any” > selection="$aDisplayGroup.queryMatch.toApplicantApplicationNamespace > //VALID" /> > > Cheers, > AARON ROSENZWEIG / Chat 'n Bike > e: [email protected] t: (301) 956-2319 > > > On Mar 25, 2014, at 6:09 PM, Christoph Wick <[email protected]> wrote: > >> Aehm, yes, sorry. I meant inline bindings. >> >> AFAIK there's nothing like the // VALID for inline bindings. >> But I'd love to learn that there is something ... >> >> C.U.CW >> -- >> What are the three enemies of a programmer? Sunlight, oxygen, and the >> appalling roar of the birds. >> >> On 25.03.2014, at 23:01, Chuck Hill <[email protected]> wrote: >> >>> I would have thought that WOGNL expressions were exempt from validation. >>> If not, the //VALID should work for them too. >>> >>> Did you mean inline bindings? I am not sure if there is anything to use >>> with inline bindings. >>> >>> Chuck >>> >>> >>> On 2014-03-25, 2:57 PM, "Christoph Wick" wrote: >>> >>> Hi Chuck, >>> >>> is there something like the "// VALID" marker if you are using WOOngl? >>> >>> "// VALID" is working only if you are using WOD, isn't it? >>> >>> C.U.CW >>> -- >>> What are the three enemies of a programmer? Sunlight, oxygen, and the >>> appalling roar of the birds. >>> >>> >>> On 25.03.2014, at 17:47, Chuck Hill <[email protected]> wrote: >>> >>> The // VALID marker is the intended way to fix validation problems like >>> this. >>> Chuck >>> On 2014-03-25, 7:33 AM, "Filippo Laurìa" wrote: >>> Hello everybody, >>> I have a simple `component id generator` that implements >>> `NSKeyValueCodingAdditions`. Something like this: >>> public class ComponentIDGenerator implements NSKeyValueCodingAdditions { >>> private String idBase; >>> public ComponentIDGenerator( >>> WOComponent component) { >>> idBase = "_" + component.context().elementID().replace('.', '_'); >>> } >>> public Object valueForKeyPath(String keypath) { >>> return get(keypath); >>> } >>> public String get(String keypath) { >>> String suffix = keypath.replace('.', '_'); >>> return idBase + "_" + suffix; >>> } >>> ... >>> } >>> I pasted it because it is really simple to understand. >>> When initializing a component (in the appendToResponse() method) the >>> generator is called like this: >>> `String idFor = new ComponentIDGenerator(this);` >>> In the wod, when I try to access keys like: >>> `idFor.foo` or `idFor.bar` i get WO Template errors from WOLips: >>> "there is no key foo for the keypath idFor". >>> It's useless to say that at runtime everything runs fine. >>> I found two ways to workaround this issues: >>> 1) use WOGNL expression in the wod. So i use ~idFor.foo >>> 2) foreach key create a getKey method. For example: getFoo() >>> return idFor.valueForKey("foo").toString(); >>> I don't like those two ways: >>> the first because it is not our purpose to use WOGNL framework in the >>> application, >>> the second because the work load becomes very huge. >>> Maybe there is a third way: >>> put // VALID next to the wod defecting property-value pair, like >>> id = idFor.foo; // VALID >>> I want to know if is there a correct way to remove this kind of errors >>> between those i mentioned before, or maybe something better. >>> Thank you for reading. >>> Regards, >>> Filippo Lauria >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>> This email sent to [email protected] >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/wicki%40me.com >>> This email sent to [email protected] >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
