in reply to My first package - need help getting started

Nice thinking, here is some thought I have.

I see three classes here:
  1. Parser
  2. Filter
  3. Formatter
The data would flow in this direction: Parser => Filter => Formatter.

  1. The Parser takes a stream of characters, and parses it into structured data.

    The Parser would have methods allow you to provide the input, which is the entity would be processed. It might be a file, might be a string...

    The Parser would parse the input into records (could be the same as lines), and each line into fields. You would allow the user to specify some criteria, and define how the records would be extracted, and then how to seperate each record into fields. Those criteria might regexps.

    For example, if we look at the sample data you give, you might want to make each line into a record, and within each record, the part before ':' is one field, the part after is another field.

    The Parser should also have methods allow you to fetch records, and fields, which would be used by the Filter.

  2. The Filter would accept structured data come out from the parser.

    You would allow the user to define the criteria as what would be threw away, and what can pass thru the Filter. Again, regexps might be a good fit here.

    The Filter does not modify the structure of the input data, but the number of output records could be less than the number of input records, if some records are threw away by the Filter.

  3. The Formatter would take the structured data, format them back to stream. Of course, the stream is formatted, and well presented.

    A good way is to allow the user define call back function, and the call back function would format those records, not your module, but your module might provide default format method, if one is not provided by the user.

I am thinking it would be really nice, if you found a way to wrap around those well known HTML parsers, and XML parsers, and make them available to your Filter.

One thing you may want to do, is to have a generic Filter class as the root, and have some generic method defined. Base on this, you then have some more specific Filters, for example, you may have one filter understand the output from a certain xml parser.

You said that you didn't want someone to do it for you, but only want some ideas. The fact is nobody can do this for you ;-), quick and good.

  • Comment on Re: My first package - need help getting started

Replies are listed 'Best First'.
Re: Re: My first package - need help getting started
by Limbic~Region (Chancellor) on Feb 27, 2003 at 03:56 UTC
    pg,
    Spot on! - except the filter (or at least I think).

    I do not think (I could be wrong here) that the filter method should be part of the module. As in:

  • Stream of data is turned into object by module
  • Object is tested by program and possibly rejected
  • Object is possibly manipulated by program
  • Object is converted back to stream by module

    This allows the greatest flexibility over the filtration process as I do not know of all the ways it is currently being used, let alone all the way that it might be filtered on in the future.

    I really like the idea of having a default format method, but allowing it to be dynamic.

    This has really given me something to think about - would you mind critiquing some very bad code as soon as I get started? I have never built an object before, so I know my first attempt will be bad. If not - that is ok too.

    Thanks again and cheers - L~R

[reply]
      ;-) Lots of time, you would see more than one design fly, and each of them is good. There is no black and white answer, and this is why computer science is both science and art.

      I agree that you can start with filter as part of your program, instead of a seperate module, but later if you see the functionality need to be reused, then abstract/extract a class out of your existing code.

      The traditional software engineering requires you to have everything laid out at the beginning, the design phase, and there is only one design phase. The modern software engineering does allow you to create your software cycle by cycle, each cycle is a whole traditional software life cycle, and has its own design phase. For each new cycle, new functionality would be added, and the design would be modified in a constructive way.

      This change of methodology is mainly because:

      1. people found there is no way that the traditional methodology would work for big systems/projects. It is simply impossible for people to get everything straight and right, once for forever.
      2. From a business view, companies some time want to be the first in the market. They have to prototype things, and quickly make their products available, worry more functions later.
      For sure, I would like to be one of the persons to do code review for you. By doing that, we can learn from each other.
[reply]

In Section Seekers of Perl Wisdom