Re: wocomponent wizard preview

From: Chuck Hill (chil..lobal-village.net)
Date: Mon Feb 23 2009 - 14:46:17 EST

  • Next message: Andrew Lindesay: "Re: wocomponent wizard preview"

    On Feb 23, 2009, at 6:57 AM, Mike Schrag wrote:

    > I think I'm mostly with Q here ... I definitely appreciate what
    > you're trying to achieve, but I REALLY want to make WOLips easier,
    > not harder for people, and almost everything on that dialog is at a
    > complexity level that most WO devs don't want to deal with or think
    > about.

    I think this is an important point. One of the problems with Eclipse
    is that (paradoxically) it is too configurable. Options, options,
    options everywhere! Even if you know what they are it is hard to
    remember where they are. If these have to be available, they should
    at least be hidden by default. Even the existing wizard is IMO more
    complicated than it needs to be. I like Q's comments on the .api
    file. It is created on demand, so why both with it at this stage?

    > <WOComponentWizard preview 1-1.jpg>
    > * I like Q's idea of having a couple templates ... For the most
    > part, people are either doing Bundle components or HTML File
    > Components (which aren't even really fully supported yet, but it
    > will be). I think you can basically remove all those options at the
    > top if you have this picker.

    HTML File Components go directly in Resources/ or have to be under
    a .wo/ directory?

    >
    > * I'm OK with the Source folder at this point ... It's really a
    > Maven-only thing, but it needs to be there as a result, so we have
    > to suck that one up, I think (though technically it could only
    > appear if it's a Maven project)

    Is there any need to show it, if there is only one? Is this not also
    set at the project level for Maven projects?

    > * Modifiers just isn't worth it ... I've never created a non-public
    > Component. As far as abstract, if your component is abstract, you
    > don't have a component file, so it's just a Java file, so I think
    > you would just use the new Java file wizard (and I think you'd know
    > to do that because if you're making an abstract component, you're an
    > advanced user). Final, i've NEVER done.

    +1

    > * Interfaces ... I think it's not worth having here ... The number
    > of people who put interfaces on components, I suspect, is tiny.

    Also agree. I do this from time to time, but I'd rather have a clean
    wizard and add these later. Usually it is quicker to just type
    "implements HelpContextPage" than to use this picker.

    > * For the method stubs, I think remove them and just make them both
    > true automatically. I would wager this is nearly always right and
    > only a minor annoyance to fix up in the tiny percentage of cases
    > where it isn't right.

    +1

    > * For comments, I'm pretty sure there are global defaults for this
    > -- I think just use the global defaults and don't bother giving an
    > option here.

    +1

    > * In my opinion, holding up Eclipse's existing wizards as a design
    > model is a bad idea. Eclipse is awesome at making terrible,
    > confusing, and busy UI's.

    +10,000 It seems like a nasty bit of Design by Committee with
    everyone's option getting in and not though to ease of use for the end
    user.

    Chuck

    > On Feb 23, 2009, at 9:38 AM, Q wrote:
    >
    >>
    >> On 23/02/2009, at 10:34 PM, Lachlan Deck wrote:
    >>
    >>> On 23/02/2009, at 10:23 PM, Q wrote:
    >>>
    >>>> On 23/02/2009, at 5:58 PM, Andrew Lindesay wrote:
    >>>>
    >>>>> Hello Lachlan and Quinton;
    >>>>>
    >>>>>> Optional WOO file creation was previously a feature of the
    >>>>>> wizard, but was removed for good reasons (that I don't recall
    >>>>>> right now).
    >>>>>
    >>>>> I was quite keen on not having the woo with my components.
    >>>>
    >>>> What I do remember of the problem is that this happened at a time
    >>>> when quite a number of people were migrating from xcode and
    >>>> having no end of character encoding related issues.
    >>>> As a result the Apple WO team proposed that character encoding
    >>>> validation be added to WOLips to ensure that eclipse's idea of
    >>>> the character encoding matched what WO was expecting.
    >>>
    >>> For the woo, wod, html or all three?
    >>
    >> woo file is always UTF-8, wod and html are whatever is specified in
    >> the woo file, if not specified a check for UTF-16 content is
    >> performed then otherwise assumed to be whatever the WO runtime
    >> default encoding is.
    >>
    >>>> This was done by me, and it sort of worked, except that WO
    >>>> doesn't have a default encoding type, it uses the JDK default
    >>>> which is different depending on the platform you use, so it was
    >>>> not possible to validate the encoding type when it was
    >>>> unspecified because this could change depending on the JDK you
    >>>> used to run the app.
    >>>>
    >>>> More recently the move in the wolips & wonder communities has
    >>>> been to standardise on using UTF-8 as the default component
    >>>> encoding type, which is only possible to do correctly, due to
    >>>> WO's lack of defaulting to UTF-8, if your component includes
    >>>> a .woo file stating that you are explicitly using UTF-8.
    >>>
    >>> Interesting. So, if the parent container is MacOSRoman and the woo
    >>> is UTF-8 what happens?
    >>
    >> Assuming the html and wod files inherit from the parent container,
    >> you would get an encoding mismatch warning in your project's
    >> problems view.
    >>
    >>> So when a user defines the Components folder, for example, as
    >>> UTF-8 and the stuff in there inherits this ... you're saying that
    >>> this only has meaning for Eclipse and not the runtime (obvious)
    >>> and that the woo is needed for the runtime, correct?
    >>
    >> Yes. That is why WOLips includes a listener that will automagically
    >> manage the encoding in the .woo file for you when you change the
    >> encoding type of a component through the eclipse preferences
    >> interface.
    >>
    >>> I suppose this could be negated, however, if there were some way
    >>> to ensure WOMessage.defaultEncoding...
    >>>
    >>>> So it's just better to let eclipse take care of things for you
    >>>> and live with the fact that .woo files mean you don't need to
    >>>> worry about the character encoding.
    >>>
    >>> So the default will be UTF-8.
    >>
    >> The default in 5.4 is UTF-8 I believe.
    >> The default for new WO projects in WOLips is UTF-8
    >>
    >> --
    >> Seeya...Q
    >>
    >> Quinton Dolan - qdola..mail.com
    >> Gold Coast, QLD, Australia (GMT+10)
    >> Ph: +61 419 729 806
    >>
    >>
    >>
    >

    -- 
    Chuck Hill             Senior Consultant / VP Development
    

    Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects



    This archive was generated by hypermail 2.0.0 : Mon Feb 23 2009 - 14:46:59 EST