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

RE: [pcgen-xml] XML plan summary - XML dependacies

Expand Messages
  • CC Americas 1 Carstensen James
    ... PCGen ... an ... needs ... using ... You still have your sources, this would be only to bring in parts of additional sources. For example, say that
    Message 1 of 4 , Mar 4, 2003
      Keith wrote:
      >> 3. A solution for both might be instead of putting in /file/
      >> dependencies in the files, put in /XML ID/ dependencies and have
      PCGen
      >> (eventually, not phase 1) determine what it's missing and look though
      an
      >> (automatically generated) index of the LST files to find which it
      needs
      >> to include. (I'd suggest a default index in the DL and a tool option
      >> instead of reindexing on each load just for speed reasons. Maybe
      using
      >> the LST editors would auto-kick off a reindex.)
      >
      >I'd considered putting IDs on the individual files and just specifying
      >in each file which file IDs need to be satisfied, but I figured it
      >wouldn't fly right now. What you're describing is different, but an
      >interesting idea. I'll need to think about it.
      >
      >The index *should* be pretty static. The only times it would change is
      >when things are added or removed, so there would be no real need to
      >regen it each time. However, one downside is that it might load *only*
      >what is needed, not necessarily what is desired, or that it might
      >require the load of entire files when only a small part is needed.

      You still have your sources, this would be only to bring in parts of
      additional sources.

      For example, say that "Monte's Ranger" was in "Monte's Web Stuff" which
      also contained other things. A DM modified the favored class for elves
      to Monte's Ranger, but aren't using anything else from Monte's Stuff.

      The DM loads SRD, Splatbooks (from CMP), and Traps & Treachery. The SRD
      sees that as a favored class for Elf it needs "class.ranger-monte-cook".
      It finds in the index to know which file, and adds it to the
      too-be-loaded list (or the "you need this source too should I add it"
      list). (And of course since you just added a source you need to check
      for additional dependencies, but you would need to do that anyway.)

      Yes, this functionality can currently be done with the PCC file - it
      would be expanding on it just like XML file dependencies would expand it
      with two critical differences.

      1. Finer granularity - only load exact dependencies, not whole file for
      one dependency.
      2. Doesn't need to be maintained.

      >I have considered predeclaration of data -- a file that contains the
      IDs
      >and *bare minimal* information about things being used (name,
      >basically). Later files would modify these declarations for actual
      use.
      >This would relax the dependencies between data because they could be
      >formally linked when used.

      This could be automatically generated, and be the index we were talking
      about above if we also included the file to load from. This would also
      stop the need for modifying it from later files, keeping it cleaner. In
      my book the more places we automate things people shouldn't need to
      think of, the better.

      >That is, if 'races.xc' needs class IDs, it might load 'classes.xh'.
      All
      >IDs are satisfied, so processing can continue. If someone uses 'elf',
      >it may need information about 'wizard' and so will trigger loading
      >'classes.xc'.

      Ah, this would cut down on the load time of the index. However, an
      index that doesn't need complex parsing (all the same format: XML ID =
      this filename), only needs to be gone through once, and can be discarded
      after source load doesn't sound like it should be too resource
      intensive, either in terms of time or long term memory usage.

      >I'm not sure if this is a simplification or not. I do know that
      >maintaining the information, even minimal information like this, in two
      >files will not be popular.

      That's why I'm suggesting that we automate it. it's really along the
      lines of a recursive grep through the data directory for the id tag, and
      generating a list of id tags to the file they exist in.

      Bad perlish pseudopodia

      my %foundin;
      my @files=get_filenames; #(recursive opendir to get list of filename)

      foreach my $file (@files) { # Go through files, load into $file
      next if /^\./; # Skip . & .. on UNIX platforms
      open (IN,$file); # Open file
      while <IN> { # Read each line, put in $_
      next unless /<\s*id\s*=\s*"([\w\.\-]+)"\s*>/; # Skip
      unless has a id tag, and put contents of tag in $1
      $foundin{$1}=$file; # load hash %foundin with filename
      keyed by XML ID
      }
      close IN;
      }

      Sorry, very message and that's not the nicest regex. (For everyone else
      reading, the line next unless /<\s*id\s*=\s*"([\w\.\-]+)"\s*>/; should
      be read as:

      Skip to the next line unless the current line contains: less than,
      optional whitespace, the string "id", optional whitespace, an equals
      sign, more optional whitespace, double quotes, (start remembering), one
      or more of word characters, periods, or dashes, (stop remembering),
      double quotes, yet more optional whitespace, greater than.

      Not sure if I properly escaped everything, but you should get the idea.
      Read through the index file once, now for every dependency XML ID you
      know where to find it. This only works with the unique ids, but as long
      as we have them we might as well push all of this off onto the computer
      to leave people free to do the hard stuff.

      Cheers,
      Blue
    • Keith Davies
      On Tue, Mar 04, 2003 at 12:55:06PM -0500, CC Americas 1 Carstensen James wrote: ... I like the idea. Let me think about it for a bit; I think I
      Message 2 of 4 , Mar 4, 2003
        On Tue, Mar 04, 2003 at 12:55:06PM -0500, CC Americas 1 Carstensen James wrote:

        <killer snip>

        > Bad perlish pseudopodia
        >
        > my %foundin;
        > my @files=get_filenames; #(recursive opendir to get list of filename)
        >
        > foreach my $file (@files) { # Go through files, load into $file
        > next if /^\./; # Skip . & .. on UNIX platforms
        > open (IN,$file); # Open file
        > while <IN> { # Read each line, put in $_
        > next unless /<\s*id\s*=\s*"([\w\.\-]+)"\s*>/; # Skip
        > unless has a id tag, and put contents of tag in $1
        > $foundin{$1}=$file; # load hash %foundin with filename
        > keyed by XML ID
        > }
        > close IN;
        > }
        >
        > Sorry, very message and that's not the nicest regex. (For everyone else
        > reading, the line next unless /<\s*id\s*=\s*"([\w\.\-]+)"\s*>/; should
        > be read as:
        >
        > Skip to the next line unless the current line contains: less than,
        > optional whitespace, the string "id", optional whitespace, an equals
        > sign, more optional whitespace, double quotes, (start remembering), one
        > or more of word characters, periods, or dashes, (stop remembering),
        > double quotes, yet more optional whitespace, greater than.
        >
        > Not sure if I properly escaped everything, but you should get the idea.
        > Read through the index file once, now for every dependency XML ID you
        > know where to find it. This only works with the unique ids, but as long
        > as we have them we might as well push all of this off onto the computer
        > to leave people free to do the hard stuff.

        I like the idea. Let me think about it for a bit; I think I see a
        couple things that might cause problems and I don't have time to
        concentrate on this at the moment.


        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.