Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen-xml] Re: Reducing Sources (a feature suggestion)

Expand Messages
  • Keith Davies
    ... I m more accustomed to seeing MVC in reference to GUIs, not just abstraction and encapsulation. ... Not necessarily. There re two ways to implement a
    Message 1 of 5 , Oct 4, 2002
    • 0 Attachment
      On Thu, Oct 03, 2002 at 07:13:29PM +0000, Strom McLeod wrote:
      > --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
      > > What I was discussing was a little beyond MVC. Or a little before it --
      > > high cohesion, loose coupling. That is, *nothing* knows anything it
      > > doesn't need to.
      >
      > That's what the MVC model emphasizes.

      I'm more accustomed to seeing MVC in reference to GUIs, not just
      abstraction and encapsulation.

      > > The data engine has no knowledge of file formats or how things get
      > > loaded or saved
      >
      > Yes and No. At some point in the data access layer, you will have to
      > specify "hello, I'm using Oracle". Think of it as a display driver.
      > Above the display driver level, you only need to know which display
      > driver to call. Within the display driver level, that driver needs to
      > know specifically how to manipulated a specific video card series.

      Not necessarily. There're two ways to implement a system that uses
      Oracle. The first is where it is the primary store of the data, where
      the program gets it while working (an OracleDataEngine, if you will).
      When the front end requests the description of, say, /fireball/, it
      calls the data engine through its defined interface, then behind that
      the data engine starts sending queries to Oracle, constructs the Spell
      that contains the description, then passes it back to the caller. In
      this case, the implementation of the OracleDataEngine of couse must know
      that it's using Oracle.

      The case I was talking about, though, was that the data engine uses the
      'normal' implementation of storing everything in RAM. A DataSource will
      be used to retrieve the data from somewhere and pass the created objects
      to the DataEngine. In the XML case, that means an object will exist
      that will open the specified XML file and parse it; as it completes
      construction of business objects and loading them with their data, it
      passes those objects to the DataEngine. An OracleSource would open the
      database, suck all the related data out of it, construct the objects,
      and pass them to the DataEngine. In this case, the DataEngine has no
      knowledge that its data came out of Oracle, or XML, or LST, or whatever,
      hence my initial statement.

      The output object is the same, a client of the DataEngine. It asks the
      DataEngine for all the objects and stores them however it wishes.
      Again, the DataEngine does not know that this is XML, LST, or Oracle.

      > > When we get around to coding, I intend to design something that hides
      > > that information from whatever's using it. I don't want client code
      > to have to know (beyond the creation of the data engine) what type of
      > > engine it's dealing with (in memory, Oracle, whatever).
      >
      > yes, you're reiterating what's in J2EE and the MVC model.
      >
      > > Data Engine
      > > ^ ^
      > > | + In Memory Data Engine
      > > |
      > > + RDBMS Data Engine
      > > ^
      > > + Oracle
      > > + PostgreSQL
      > > + Access
      >
      > Try this instead:
      >
      > Data Engine
      > ^ ^...... Objects representing data in memory
      > |
      > Data Access Layer
      > ^
      > |
      > | (SQL Statements)
      > |
      > JDBC Driver -> any database that has a jdbc driver

      Sure. The beauty of this is that it isn't necessary to do it only one
      way. It's an implementational issue well away from where we're trying
      to do here right now.

      > > OTOH, if you want to recover from the error that's best done close
      > to the source of the error ('value for F not found, using default');
      > in this case I'd find exceptions a cumbersome mechanism.
      >
      > What you said above is exactly what you do in the 'catch' clause of
      > the exceptions mechanism, Keith.

      Remember, I'm not *that* accustomed to Java exceptions. I found them
      intrusive, when I've got more experience with another mechanism. I am
      also aware that I wasn't expressing myself well in earlier posts.

      I'll stipulate that they can certainly work, that it might be the
      correct way to do it in Java, but that my preference is to not use them
      for expected errors. Anticipated errors, yes -- those that I think can
      happen and need to plan for -- but not necessarily those that I know
      will happen. I'm not saying that using exceptions is wrong, just that
      my experience has been *not* using exceptions.

      It's a style issue from another language.

      > Here's the structure of a hypothetical program:
      > You have a input handler called userInputHandler, which keeps track of
      > which set of inputs it is expecting, perhaps with information about
      > which screen the user is in.
      > Let's say it's getting the 6 attributes. So it loops through a list,
      > starting with Strength, which is listed as a pair, ["Strength",
      > "Int"], followed by ["Dexterity, "Int"] and so on... so that the input
      > parser knows to expect an int.
      >
      > All this is done using the exception pattern.
      >
      > textInput.parse doesn't need to know that it's going for Strength
      > verses Character Name, it only cares about the type you expect it to
      > return. The caller can decide how to handle that exception depending
      > on the case.
      > You write one parser, you call it many times, the caller knows what to
      > do if something bad/exceptional happens.
      >
      > again, your mileage and style may vary, but the exception handling
      > paradigm goes pretty much as described above, using try-catch clauses.

      It certainly seems a reasonable solution.


      Keith
      --
      Keith Davies
      keith.davies@...

      PCGen: <reaper/>, smartass
      "You just can't argue with a moron. It's like handling Nuclear
      waste. It's not good, it's not evil, but for Christ's sake, don't
      get any on you!!" -- Chuck, PCGen mailing list
    • Strom McLeod
      ... It s not, it s a pattern for developing the whole system, not just the GUI. ... The whole point is to not need to specify exactly what database will be
      Message 2 of 5 , Oct 4, 2002
      • 0 Attachment
        --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
        > I'm more accustomed to seeing MVC in reference to GUIs, not just
        > abstraction and encapsulation.

        It's not, it's a pattern for developing the whole system, not just the
        GUI.

        > Not necessarily. There're two ways to implement a system that uses
        > Oracle.

        The whole point is to not need to specify exactly what database will
        be used and allow that to be abstracted throughout most of the system.

        You specify the details of the database/datasource to be used in a
        configuration file, in addition to a nickname that will be used to
        reference that database/datasource. You can switch databases used to
        realize without changing the nickname.

        The rest of the application uses the nickname to run SQL statements
        etc. without worrying about what driver is actually being used.
        There's no reference to 'Oracle' within the code, only "the database"
        or datasource.

        Technically, you should further encapsulate these SQL statements into
        a data access object/package that the rest of the system calls, so
        that all your SQL calls are centralized into one manageable place.

        Now, if you've already got how you want to architect and design this
        in mind already, as the rest of your post suggest, and given that I'm
        not even a recognized primate, I'll leave it be.

        Good luck
      • Keith Davies
        ... Yep. I discussed Oracle only as an example, and that I expect that the general design of the software would be such that, outside what the implementations
        Message 3 of 5 , Oct 4, 2002
        • 0 Attachment
          On Fri, Oct 04, 2002 at 09:02:02PM +0000, Strom McLeod wrote:
          > --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
          > > I'm more accustomed to seeing MVC in reference to GUIs, not just
          > > abstraction and encapsulation.
          >
          > It's not, it's a pattern for developing the whole system, not just the
          > GUI.
          >
          > > Not necessarily. There're two ways to implement a system that uses
          > > Oracle.
          >
          > The whole point is to not need to specify exactly what database will
          > be used and allow that to be abstracted throughout most of the system.

          Yep. I discussed Oracle only as an example, and that I expect that the
          general design of the software would be such that, outside what the
          implementations need to know, they don't need to know anything else.
          The specific example I used was that the data engine, if constructed
          correctly, will not need to know about the particular source used
          (database, XML file, LST file, etc.).

          > You specify the details of the database/datasource to be used in a
          > configuration file, in addition to a nickname that will be used to
          > reference that database/datasource. You can switch databases used to
          > realize without changing the nickname.

          Of course.

          > The rest of the application uses the nickname to run SQL statements
          > etc. without worrying about what driver is actually being used.
          > There's no reference to 'Oracle' within the code, only "the database"
          > or datasource.
          >
          > Technically, you should further encapsulate these SQL statements into
          > a data access object/package that the rest of the system calls, so
          > that all your SQL calls are centralized into one manageable place.

          This is what I would do.

          > Now, if you've already got how you want to architect and design this
          > in mind already, as the rest of your post suggest, and given that I'm
          > not even a recognized primate, I'll leave it be.

          The conversation has been useful. It's brought things to mind that I
          hadn't considered, or only superficially. I hope to be able to present
          something significant for discussion and dissection soon... but I've
          been saying that for a while now :/

          You do realize that we've been arguing the same points? <g> The only
          thing we've actually disagreed on is how to handle certain types of
          error, and in both cases the stances were based on different design
          styles and different languages... as for the rest of it, I can't think
          of anything either of us said that actually excluded what the other did.

          I do have strong opinions how my code should be built. I'm the one
          building it <g>. PCGen uses different technology (Java), and the
          techniques used to handle error conditions naturally differ. I'm
          working on the XML schema, and while *technically* it doesn't have
          anything to do with the program source, I think I must be able to
          demonstrate that the XML schema can be used for the purpose it is
          designed for. If I build a schema that does describe the data but is
          unusable, or causes us to end up with the data model problems we're
          facing now, it isn't, IMO, a good schema.

          The software design I'm working on in conjunction is only a suggestion
          as to how the data can be handled by the software. However, I suspect
          that the design may in fact be used. Even if it isn't, I don't want to
          present something technologically weak and have it get caught up in
          redesign because I did something outright stupid.


          Keith
          --
          Keith Davies
          keith.davies@...

          PCGen: <reaper/>, smartass
          "You just can't argue with a moron. It's like handling Nuclear
          waste. It's not good, it's not evil, but for Christ's sake, don't
          get any on you!!" -- Chuck, PCGen mailing list
        Your message has been successfully submitted and would be delivered to recipients shortly.