Grokbase Groups Turbine dev July 2006
FAQ
Hi Scott,
Hi Thomas,

since you two seem to be the only two left active on the Project. Did you have
a chance to lok at the patches I made to the fulcrum-parser at all?

--
Kind regards

Juergen



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Search Discussions

  • Thomas Vandahl at Jul 23, 2006 at 12:57 pm

    Jürgen Hoffmann wrote:
    Hi Scott,
    Hi Thomas,

    since you two seem to be the only two left active on the Project. Did you have
    a chance to lok at the patches I made to the fulcrum-parser at all?
    Not yet. However I promise to look into this during next week.

    Bye, Thomas.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
  • Thomas Vandahl at Jul 29, 2006 at 8:05 am

    Jürgen Hoffmann wrote:
    Hi Scott,
    Hi Thomas,

    since you two seem to be the only two left active on the Project. Did you have
    a chance to lok at the patches I made to the fulcrum-parser at all?
    Ok, here are my comments regarding the parser. They are not only about
    your patches but about the component in general.

    - The components have some logic errors (see
    ParameterParser.setUploadData() or
    DefaultParameterParser.getRepository() for examples.

    - In the BaseValueParser there is a lot of array copying going on. I
    don't believe that this is the smartest way to do things.

    - The encapsulation of the components leaves much to be desired. See
    UploadService.getFileUpload() or the Exception types thrown.

    - Please comment added methods and keep the indents. See
    UploadService.getAutomatic() and DefaultParameterParser.setRequest()

    - I think that exposing the automatic setting is not a good idea. I
    would suggest moving it from the UploadService to the Parser anyway. The
    upload service can't do something about automatic parsing at all. This
    is a configuration of the parser.

    - The handling of the component dependencies is clumsy at best. I
    believe that the parser should work without an upload service installed.

    - Strongly -1 against the inclusion of the DateSelector and TimeSelector
    classes. They are a relict of the stone age, add a unnecessary
    dependency on ECS and have nothing to do with the business logic layer.

    I fixed some of the issues above and will commit the rest of it shortly.

    Bye, Thomas.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
  • Scott Eade at Jul 29, 2006 at 11:35 pm
    Hi Thomas (this is off-list),

    Thanks for looking at this - I am totally snowed under here with my day
    (and night!) job.

    Jürgen probably had the impression that the changes in T2.3 needed to be
    ported over to Fulcrum with no changes - enhancements/improvements are
    of course fine. A change that breaks backward compatibility should
    however be noted in the change log (e.g. removal of support for
    DateSelector and TimeSelector).

    My thanks to Jürgen and you for your effort on this.

    Scott

    Thomas Vandahl wrote:
    Jürgen Hoffmann wrote:
    Hi Scott,
    Hi Thomas,

    since you two seem to be the only two left active on the Project. Did
    you have a chance to lok at the patches I made to the fulcrum-parser
    at all?
    Ok, here are my comments regarding the parser. They are not only about
    your patches but about the component in general.

    - The components have some logic errors (see
    ParameterParser.setUploadData() or
    DefaultParameterParser.getRepository() for examples.

    - In the BaseValueParser there is a lot of array copying going on. I
    don't believe that this is the smartest way to do things.

    - The encapsulation of the components leaves much to be desired. See
    UploadService.getFileUpload() or the Exception types thrown.

    - Please comment added methods and keep the indents. See
    UploadService.getAutomatic() and DefaultParameterParser.setRequest()

    - I think that exposing the automatic setting is not a good idea. I
    would suggest moving it from the UploadService to the Parser anyway.
    The upload service can't do something about automatic parsing at all.
    This is a configuration of the parser.

    - The handling of the component dependencies is clumsy at best. I
    believe that the parser should work without an upload service installed.

    - Strongly -1 against the inclusion of the DateSelector and
    TimeSelector classes. They are a relict of the stone age, add a
    unnecessary dependency on ECS and have nothing to do with the business
    logic layer.

    I fixed some of the issues above and will commit the rest of it shortly.

    Bye, Thomas.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
  • Thomas Vandahl at Jul 30, 2006 at 3:36 pm

    Scott Eade wrote:
    Jürgen probably had the impression that the changes in T2.3 needed to be
    ported over to Fulcrum with no changes - enhancements/improvements are
    of course fine. A change that breaks backward compatibility should
    however be noted in the change log (e.g. removal of support for
    DateSelector and TimeSelector).
    From my point of view, the selectors do not belong to the parser code.
    They are view components which would not even work with the Velocity
    templating engine nor JSP without tricks.

    Moreover while fixing the BaseValueParserTest I was thinking that having
    the parser as an Avalon component might be questionable at all. The
    parser is an object which normally is pooled (using the pool component
    for example). The way it is done now, you need to teach the pool service
    to lookup components from the container, which is not what we want (if
    I'm not mistaken).

    My thanks to Jürgen and you for your effort on this.
    You're welcome.

    To make myself clear: Most of the topics discussed were not based on
    Juergens patches. These are fine.


    Bye, Thomas.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
  • Jürgen Hoffmann at Jul 29, 2006 at 11:17 am
    Hi Thomas,

    thanks for looking into the patch. I have the same meaning as you do about
    things. I hav just been a bit unsure about how to do things, because as I
    understood Scott, we wanted to port the Parser from t2.3.2 into
    fulcrum-parser. That is why this is basically a first step towards that goal,
    and to get fulcrum-parser released.

    Please let me know how I can help, or let us discuss the next steps, as I
    really want to get turbine development going again.

    Kind regards

    Juergen

    Am Samstag, 29. Juli 2006 10:04 schrieb Thomas Vandahl:
    Jürgen Hoffmann wrote:
    Hi Scott,
    Hi Thomas,

    since you two seem to be the only two left active on the Project. Did you
    have a chance to lok at the patches I made to the fulcrum-parser at all?
    Ok, here are my comments regarding the parser. They are not only about
    your patches but about the component in general.

    - The components have some logic errors (see
    ParameterParser.setUploadData() or
    DefaultParameterParser.getRepository() for examples.

    - In the BaseValueParser there is a lot of array copying going on. I
    don't believe that this is the smartest way to do things.

    - The encapsulation of the components leaves much to be desired. See
    UploadService.getFileUpload() or the Exception types thrown.

    - Please comment added methods and keep the indents. See
    UploadService.getAutomatic() and DefaultParameterParser.setRequest()

    - I think that exposing the automatic setting is not a good idea. I
    would suggest moving it from the UploadService to the Parser anyway. The
    upload service can't do something about automatic parsing at all. This
    is a configuration of the parser.

    - The handling of the component dependencies is clumsy at best. I
    believe that the parser should work without an upload service installed.

    - Strongly -1 against the inclusion of the DateSelector and TimeSelector
    classes. They are a relict of the stone age, add a unnecessary
    dependency on ECS and have nothing to do with the business logic layer.

    I fixed some of the issues above and will commit the rest of it shortly.

    Bye, Thomas.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

    !EXCUBATOR:1,44cb16bf43383987321471!
    --
    Kind regards

    Juergen



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriesturbine
postedJul 21, '06 at 10:29p
activeJul 30, '06 at 3:36p
posts6
users3
websiteturbine.apache.org

People

Translate

site design / logo © 2019 Grokbase