Re: WOLips Validation Preferences

From: Mike Schrag (mschra..obox.com)
Date: Fri Jun 25 2010 - 14:19:40 UTC

  • Next message: Henrique Prange (JIRA): "[OS-JIRA] Created: (WOL-1167) Error build woapplication and woframework projects with Maven 3"

    > 1) There is a heading "Binding Validation" just above Component Validation that seems to be completely extraneous, or am I misunderstanding what it's there for?
    it's supposed to be a description of the preference page, but it was never written ... This page recently was renamed from "Binding Validation" to just "Validation" -- so that's the old name of the page.

    > 2) Component Validation checkbox - to me a "Component" is the .wo "package" including HTML, WOD, WOO, etc. What does toggling Component Validation do?
    It's the parent toggle for all of the validation settings. It will turn off HTML validation, wod validation, binding value validation, etc.

    > 3) Auto-Insert "{", ":" and "=" - while this is great, they are not really Validation options.
    Yeah, I know. This page didn't start out being the "Binding Validation" page. It turned into that as we added more and more validations over the years. This setting SHOULD move over to the WOD editor page, but IIRC the preference group of the setting would have to change, which would lose the setting value for people who already have this set. I just decided to leave it for now.

    > 4) Inline Bindings - I assume this means turning off validation of inline bindings all-together. Should this be a sub-option to the Component Validation option because if Component Validation is off, then you wouldn't still validate inline bindings, right?
    This used to control a lot more, but many parts of the system got smarter and they just figure it out for themselves. There is only one place that uses the value, now, and that's the InsertComponent dialog -- the dialog that appears when you click one of the insert component buttons in the editor view. This setting will likely go away sometime in the 3.6 lifecycle.

    > 5) Binding Value Validation (Slow) - Does this apply to all values to all bindings, either inline or WOD-based? Should this also be a sub-option of the Component Validation option?
    Yes, it is overridden by the "Component Validation" option. It applies to inline or wod -- they're internally the same model.

    > 6) WOO Encoding Validation - Again, should this be a sub-option of Component Validation?
    Yes, it's overridden by "Component Validation," too.

    > In the area where you set the error-reporting levels I'm unclear on what some do:
    Keep in mind that these controls are brand new, and likely will change during 3.6 development.

    > 1) WOD Problems - what problems does this catch that are not included in WOD API, Unused WOD Elements, WOD Errors in Template?
    I broke out some of the problems more. This used to apply to several miscellaneous problem types, but now only applies to "The class for '" + elementTypeName + "' is either missing or does not extend WOElement." This setting will be renamed.

    > 2) Ambiguous Key Paths - I just don't know what this is.
    An ambiguous key path is any key path that can be proven to be correct. There are actually subcategories of this that we have specific controls for, but this is the fallback for any other types that we don't specifically break out. For example, a binding on a class that implements NSKeyValueCoding -- we can never prove this to be right or wrong, a binding on a WOComponent (which is a subcategory of that problem, but very common, so broken out), a binding on a collection (again, a KVC one, but common, and broken out), or any binding against a java.lang.Object type.

    > 3) Helper Functions, are these the WOOGNL Helper Functions discussed here: http://wiki.objectstyle.org/confluence/display/WOL/WOOGNL+Helper+Functions ?
    Yes. We don't currently resolve the helper classes in wolips, so we can't validate the correctness of these. So you can either have wolips give you a warning on every one saying that, or you can turn it off and not care.

    > 4) Require well-formed HTML Template - it is set to Default. What's default? Where does it get the default from?
    The default is computed per-project based on the frameworks you link to. If you link to WO 5.4, the default will be that you DO want well-formed html templates. If you are 5.3, it will be false. Technically this is a default-default, because you can override this in bulid.properties per-project (the component.wellFormedTemplateRequired flag). So this is saying, if you don't specify that override on the project, then what should the default value be. If you specify "Default" in the global setting, it will be dynamically computed. You may, however, have a case where you use 5.4, but you use WOOgnl everywhere (or some other template parser) and you don't want this restriction on ever, so you could force it off.

    ms



    This archive was generated by hypermail 2.0.0 : Fri Jun 25 2010 - 14:20:37 UTC