flatworm-users — End user discussion and question list for Flatworm

[Flatworm-users] Help on Repeating Segments

[Rodrigo C. <roc...@gm...>]

Hi Guys, I'm Rodrigo Camargo from Brazil and I'm testing the flatworm for a
big project I have here. The point I didn't get it very well is the
repeating segments. The only example at Flatworm website is using the pipe
separated string, but I intent to use it by position defined. So I changed
my XML accordingly and this is not working. The "add" method is not being
called. There is no error also, and I'm lost. Could you please send me an
example of a simple configuration like this:

To be parsed:

ABC.......DEF.....DEF.....DEF..... (maybe more DEF ahead)

So, the main bean is ABC with three segments DEF.
What I did is after the configuration of ABC (which is working by the way),
I've included the <segment-element> with the DEF bean.

<?xml version="1.0" encoding="ISO-8859-1"?>
<file-format>
<converter name="char"
class="com.blackbear.flatworm.converters.CoreConverters"
method="convertChar" return-type="java.lang.String"/>
    <converter name="decimal"
class="com.blackbear.flatworm.converters.CoreConverters"
method="convertDecimal" return-type="java.lang.Double"/>
    <record name="ABC">
        <record-ident>
            <field-ident field-start="0" field-length="3">
                <match-string>ABC</match-string>
            </field-ident>
        </record-ident>
        <record-definition>
            <bean name="abc" class="com.mypackage.ABC"/>
            <bean name="def" class="com.mypackage.DEF"/>
            <line>

            ... (fields for ABC)

<segment-element parent-beanref="com.mypackage.ABC" addMethod="addDEF"
beanref="com.mypackage.DEF" minCount="1" maxCount="2"
cardinality-mode="STRICT">
                 <field-ident field-start="0" field-length="3">
                 <match-string>DEF</match-string>
             </field-ident>

             <record-element length="3" beanref="def.type" type="char"/>
                          ... (other elements of def)
</segment-element>
            </line>
        </record-definition>
    </record>
</file-format>


This is not working and there is neither error nor warnings. Could you
please help?

Thanks a lot,


 RODRIGO CAMARGO
 roc...@gm...

[Flatworm-users] Reading and Writing Delimited Files with the same Flatworm Configuration File

[Graziano, M. <mig...@di...>]

Hi Flatworm Users,

I was wondering if someone could help me with this.  I have used Flatworm very successively to write pipe delimited files.  I now have a need to read the same file that I wrote and I thought that it would be reasonable to do so with the same XML configuration file that I used to write it.  From what I am seeing that is not the case.  The problem I am encountering is that upon reading the file, the record identifier is read as the first field and an attempt is made to add it to my bean.  For example, consider this extremely stripped down config file segment:

  <record name="Ftr">
              <record-ident>
                          <field-ident field-start="0" field-length="5">
                                      <match-string>MYFTR</match-string>
                         </field-ident>
               </record-ident>
  <record-definition>
      <bean name="ftr" class="com.mjg.flatworm.bean.Ftr"/>
      <line delimit="|">
      <record-element length="8" beanref="ftr.recCnt" type="integer">
          <conversion-option name="justify"             value="right"/>
          <conversion-option name="pad-character" value="0"/>
      </record-element>
  </record>

A file like this dutifully creates a record like

MYFTR|00000008|

However, when I try to read that record using the same XML config file, Flatworm associates MYFTR with the bean element ftr.recCnt and it is unhappy since MYFTR cannot be parsed to an Integer.

I tried

  <record name="Ftr">
              <record-ident>
                          <field-ident field-start="0" field-length="5">
                                      <match-string>MYFTR</match-string>
                          </field-ident>
               </record-ident>
  <record-definition>
      <bean name="ftr" class="com.mjg.flatworm.bean.Ftr"/>
      <line delimit="|">
      <record-element length="8" type="char"/>
      <record-element length="8" beanref="ftr.recCnt" type="integer">
          <conversion-option name="justify"             value="right"/>
          <conversion-option name="pad-character" value="0"/>
      </record-element>
  </record>

and I can now read, but when I write, I get

MYFTR||00000008|

and I do not want the ||.

Do I need a separate config file for reading and writing or am I doing something wrong?

Thx & rgds

mjg

________________________________

CONFIDENTIALITY NOTICE
This transmission is intended for the sole use of the individual and/or entity to whom it is addressed, and may contain information and/or attachments that are privileged, confidential and exempt from disclosure under applicable law. If the reader of this transmission is not the intended recipient, you are hereby notified that any disclosure, dissemination, distribution, duplication or the taking of any action in reliance on the contents of this transmission by someone other than the intended addressee or its designated agent is strictly prohibited. If your receipt of this transmission is in error, please notify the sender by replying immediately to this transmission and destroying the transmission. For your protection, do not include Social Security numbers, passwords or other non-public and personal information in your email. Thank you.

[Flatworm-users] Generating Java code for the beans

[Arnout E. <arn...@bz...>]

Hi,

I think it'd be useful to also be able to generate simple Java bean code 
for the beans to be filled with flatfile. Any idea what would be the 
easiest way to do that?


Arnout

[Flatworm-users] Hey, loyal flatworm fans!

[James T. <tu...@bl...>]

I just did a major check-in of code from James Lawrence over at
Southwest Airlines (I'm a frequent SWA flyer, so nice to know they're
supporting OSS development.)  I haven't had time to look it over in
detail yet, and it'll need doc and unit tests before I can release it as
1.1, but I wanted to at least get it in the source tree.  Here's James'
notes on his additions...
=======================================
Well, I have spent the last month making most of the mods I spoke with
you earlier about.  Unfortunately, I have not had time to participate in
the sourceforge process.  My schedules are tight and when I am done
delivering this to my Customers, I have to move on.

I want to thank you personally for writing Flatworm.  It has been a
learning experience getting under the hood and enhancing (without
hopefully breaking) all that has come before.  It was very nice not to
have to start from scratch.   I hope my contributions will be worthy for
inclusion in future versions as it would be nice to consider Flatworm a
3rd party tool and benefit from future enhancements by others.

With that said, I am sending you this jar file with everything I have
done so far. (basically a tarball) It is not the final production
version, but the API is pretty stable.  All of these changes have been
driven  by Customer requirements.

What I have done.. (at least made a feeble attempt at)

1) Added support for delimited file
2) Added support for writing flatfiles
 - Created examples to demonstrate new functionality
3) Encapsulated much of the main() functionality in your previous
examples into new classes called FileParser, FileCreator
 - This allows the client to use Flatworm with less knowledge of the
internal workings.
4) Delegated type conversion and string manipulation to
ConversionHelper.  Since FileFormat was so involved in parsing and I
needed conversion for
5) Pretty heavily refactored the way type conversions and string
manipulations work.
 - string manipulation routines have moved into the Util class for
re-use by the writing portion of the code
 - since pretty much all converters were calling removePadding(), this
was refactored out.  This method has been replaced by
ConversionHelper.transformString()
   - this will allow others to create converters and not have to worry
about calling string conversion, this is done automatically by
ConversionHelper
6) Renamed the examples, xmlfiles, input file to be self-explaining
7) Moved 'beans' (or what we call domain objects) to a separate folder
  - examples folder was getting a little crowded
  - might consider moving input files and xml files to their own home
too
8) Writing a crude Quickstart guide to explain (on a very high level)
what each example does and which arguments each needs.
9) Changed the way parsing is handled.  Parsing now works similar to
the way the SAX parser operates.  It's event driven.
  - you register a callback to handle each bean type
  - you register an exception handler to deal with lines in the file
that don't parse
    - you need this if you want to do something special with the
offending line, such as write it to a file for human intervention.
(manual cleanup of the record)
10) Added two new exception types to keep client exception handling
simple.
 - FlatwormCreatorException - Used by FileCreator to wrap a myriad of
Exceptions
  - Client is still responsible for handling
 - FlatwormParserException  - Used by FileCreator to wrap a myriad of
Exceptions
11) Probably other stuff I forgot, this is the first time I have tried
to write it all down.

What I still must do..

1) Write some junit tests
2) Update the documentation
3) Update the DTD
  - I added 1 new properties to line
    - delimit- which tells the parser we are not dealing with a fixed
record type.
  - added a substring conversion-option.
4) Record matching needs to consider delimited files

Possible future features...

1)  Add support for returning an object tree Vs. single beans
 - In working with Kodo & Hibernate, this feature seems like it should
be there
 - This would work nice if you had an object that contained list of
other objects. (in our case a ticket contains a list of 4 coupon
records)
   - it would be nice to get back a single object with everything ready
to go.  Currently, the 'handler' would have to construct one and pass it
on to the business layer.
2)  I think there needs to be further refactoring of how a line is
actually parsed.  I have a PERL file parser that can even handle binary
files.
  - Record matching still assumes fixed format.
  - We need to be able to ask the Line about a specific field by it's
index, regardless of how it is actually implemented in the input file.
  - Maybe come up with some sort of plugable architecture that allows
various storage strategies to be considered.

I am sure there will be enhancements/fixes that arise out of my
Customers actually using Flatworm to create real programs.  They have 4
due by the end of this month.

I realize that you might not have the time to digest all that I have
done.  If so, that's ok.  But I would like to give you a chance to
incorporate what I have done into your open source initiative, or at
least comment on it.  I am going to submit myself to peer review here
also. Any feedback you can offer would be greatly appreciated.  I will
be happy to share the final production version of everything Flatworm
should you still have interest in what I have done.

thanks...

James Lawrence
Southwest Airlines - Technology Department
jam...@wn...
W(214) 792-6195
-- 
James M. Turner
Product Review Editor, Linux Journal
Senior Contributing Editor, Linux Planet

tu...@bl...
603-552-2020