Hitachi Vantara Pentaho Community Forums
Page 2 of 2 FirstFirst 12
Results 11 to 12 of 12

Thread: The road ahead : 3.0/4.0

  1. #11
    HDupre Guest

    Default Re: The road ahead : 3.0/4.0

    On Apr 16, 7:13 am, "Matt Casters" <mcast... (AT) pentaho (DOT) org> wrote:
    > Well, you can't have one without the other. Some plugin migration manual
    > would have to be written and it's going to get ugly if we don't pay
    > attention.


    If things are going to break what about changing the way tasks save
    their properties. Have a unique API for loading saving properties in
    xml or in the repo and eventually even have a generic GUI?

    For instance an XSLT processor could have a property object like

    public class XSLTProperties {

    @Property("File set")
    private FileSet _files;

    @Property("Style")
    private File _style;

    @Property("Output directory")
    private File _outDir;

    ...
    }

    and the framework would take care of loading and saving + generate a
    simple GUI. This could reduce considerably the code for writing a
    trans or job. On the same lines, it would be nice to have a version
    support for tasks.


    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

  2. #12
    Matt Casters Guest

    Default RE: The road ahead : 3.0/4.0

    Even besides the fact you're using 1.5 code here and then even ignoring the
    change of subject, I'll bite.

    First of all, your example is far too simple. Once it starts to become a
    little bit more complex this system breaks down... Badly.
    Here are a few of the issues I have with this system, off the top of my
    head:

    - loading XML from older versions into new once (maintaining backward
    compatibility) is a serious pain
    - saving/loading complex data types in a decent way needs more than just a
    few annotations, it needs a certain hierarchy.
    - generating readable XML without tons of classes in it "Xstream" style is a
    problem without a good solution
    - there are no simple GUIs worth using, there are exceptions in most of 'm.
    There are tons of discussion forums to look at the threads there, pick a
    side, I don't care.
    - you are still putting the metadata in the source code, e.g. replacing an
    "evil" thing with a bad thing. Just because you use annotations, doesn't
    make it OK.

    Because you didn't read my reply in the other thread, I'll repeat myself
    here: this is open source. Write code. Re-write TextFileInputMeta/Dialog,
    see what happens.
    Anything is welcome.

    All the best,

    Matt



    -----Original Message-----
    From: kettle-developers (AT) googlegroups (DOT) com
    [mailto:kettle-developers (AT) googlegroups (DOT) com] On Behalf Of HDupre
    Sent: Friday, May 04, 2007 12:51 AM
    To: kettle-developers
    Subject: Re: The road ahead : 3.0/4.0




    On Apr 16, 7:13 am, "Matt Casters" <mcast... (AT) pentaho (DOT) org> wrote:
    > Well, you can't have one without the other. Some plugin migration
    > manual would have to be written and it's going to get ugly if we don't
    > pay attention.


    If things are going to break what about changing the way tasks save their
    properties. Have a unique API for loading saving properties in xml or in the
    repo and eventually even have a generic GUI?

    For instance an XSLT processor could have a property object like

    public class XSLTProperties {

    @Property("File set")
    private FileSet _files;

    @Property("Style")
    private File _style;

    @Property("Output directory")
    private File _outDir;

    ...
    }

    and the framework would take care of loading and saving + generate a simple
    GUI. This could reduce considerably the code for writing a trans or job. On
    the same lines, it would be nice to have a version support for tasks.





    --~--~---------~--~----~------------~-------~--~----~
    You received this message because you are subscribed to the Google Groups "kettle-developers" group.
    To post to this group, send email to kettle-developers (AT) googlegroups (DOT) com
    To unsubscribe from this group, send email to kettle-developers-unsubscribe (AT) g...oups (DOT) com
    For more options, visit this group at http://groups.google.com/group/kettle-developers?hl=en
    -~----------~----~----~----~------~----~------~--~---

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.