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

[ARCH] PCGen Architecture Background

Expand Messages
  • Tom Parker
    Following up on a number of comments and discussions in various places (including, but not limited to this thread:
    Message 1 of 12 , Jun 15, 2009
    • 0 Attachment
      Following up on a number of comments and discussions in various places (including, but not limited to this thread: http://tech.groups.yahoo.com/group/pcgen_experimental/message/12659 ), I am going to walk through a number of the historical discussions regarding the PCGen architecture. This will help to validate my thinking as well as bring new developers up to speed.

      The intent of these posts is to get feedback, ideas, and participation. I may occasionally state things as facts that do not deserve to be stated as such. This may be a result of over-zealous copy and paste (I'm pillaging a lot of e-mail and instant message conversations) or just bad word choices. If I do not support a claim I am making, please challenge my assertion. The goal is to make our direction clear, not talk to a brick wall.

      I will tag these posts with [ARCH] to keep them clear for folks that want to track the conversations.

      Subsequent to sending out these messages, I will be posting this in some form to our Wiki. I will do this after discussion settles down and points are made clear, so I know what needs to be archived.

      This note is intended to provide a very high level background and a few key terms.

      At a high level, there are a few major subsystems within PCGen. You will probably see me use these terms throughout these notes. The first is the "Token/Loader System", which is responsible for loading data out of the LST files. The second is the "core" (responsible for processing changes to a PlayerCharacter) and the third is the Output system (I will refer to Output as including both the UI and Output Sheets, since both should display the same answers). As the architecture progresses, the current design is captured in this image: http://www.pcgen-test.org/wiki/index.php?title=File:Overall_system_figure.png ... so you may see me refer to different blocks in that diagram.

      Back a few years when the architecture work started, a number of issues were identified with the PCGen core that we wanted to clean up (I use "we" in a general PCGen sense here, since I was not part of the project yet; the work was started by others, including the first Architecture lead Devon Jones).

      One issue was that the Tokens (especially the text strings in the files) were directly used in the PCGen core. This created a very tight dependency between the persistent file format and the internal format used by PCGen. There are a number of side effects of this, including two major challenges: (1) Performance issues from String processing and (2) difficulty in modifying the program due to interdependencies.

      I view this as my main project in PCGen. While I can't guarantee it will all get done or remain our priority as this discussion progresses, the current projects I see are summarized here: http://www.pcgen-test.org/wiki/index.php?title=Architecture_Changes_5.17

      Overall, breaking the tight linkage between LST files and the core of PCGen is ongoing, but has made significant progress. There are a few places it still exists (Prerequisites, BONUS and CHOOSE in particular), but for the most part, the persistent data format (PCC and LST files) is independent of the internal "Rules Data Store". As a result, this has eliminated a portion of the String processing that took place in the core. However, significant work is still required in order to take advantage of the type safety now available in the core and truly improve performance. (I'll explain more about this later as we get into potential projects for people)

      The interdependency between different parts of PCGen has been partially addressed, especially with respect to the Token/Loader System, but still has significant work remaining. The core and output systems are still tightly linked. This can be easily demonstrated as there are a number of output tokens that are shipped with the core, rather than as plugins. This interdependency between objects can be objectively measured through the use of the acyclic dependency principle (which basically means you want to avoid code cycles or tangles, depending on the terms people prefer). The goal is to have a pure directed acyclic graph of classes.

      If you really want the gory list of factors we have balanced in the architecture work for PCGen, you can check out the Design Concepts page on the wiki: http://www.pcgen-test.org/wiki/index.php?title=Design_Concepts_for_PCGen
    • Martijn Verburg
      Hi Tom, REplying partially so you know that this is beign read :), my comments (grain of salt as I m not a regular code committer) are below. ... Cool, this is
      Message 2 of 12 , Jun 16, 2009
      • 0 Attachment
        Hi Tom,

        REplying partially so you know that this is beign read :), my comments (grain of salt as I'm not a regular code committer) are below.

        > <snip>
        >
        > The goal is to make our direction clear, not talk to a brick wall.

        Cool, this is definitely what we need, I think it's fair to say that many of us part timer coders get very lost in the code base and what should be left alone or not etc.

        > Subsequent to sending out these messages, I will be posting this in
        > some form to our Wiki. I will do this after discussion settles
        > down and points are made clear, so I know what needs to be archived.

        Great.

        > At a high level, there are a few major subsystems within PCGen.
        > You will probably see me use these terms throughout these notes.
        > The first is the "Token/Loader System", which is responsible for
        > loading data out of the LST files. The second is the "core"
        > (responsible for processing changes to a PlayerCharacter) and the
        > third is the Output system (I will refer to Output as including
        > both the UI and Output Sheets, since both should display the same
        > answers). As the architecture progresses, the current design is
        > captured in this image: http://www.pcgen-test.org
        > /wiki/index.php?title=File:Overall_system_figure.png ... so you
        > may see me refer to different blocks in that diagram.

        OK, it makes sense, I know we also have an explanation of the code section that roughly maps out what the various packages do in PCGen, perhaps this is something that can be tied in more tightly with the Arch diagram, e.g.

        "The pcgen.persistence.lst package is part of the [[Rules Data Store]] component in the PCGen architecture. It holds classes which........."

        And a simple reverse link could be added:

        "See [[Explanation of Code Base]] for which code packages to look at for this component"

        I guess I'll leave that up to yourself and James to decide if that's useful/needful.

        > One issue was that the Tokens (especially the text strings in the
        > files) were directly used in the PCGen core. This created a very
        > tight dependency between the persistent file format and the
        > internal format used by PCGen. There are a number of side effects
        > of this, including two major challenges: (1) Performance issues
        > from String processing and (2) difficulty in modifying the program
        > due to interdependencies.

        Cue howls of pain by coders, data monkeys and OS monkeys every time we changed a token ;).

        > I view this as my main project in PCGen. While I can't guarantee
        > it will all get done or remain our priority as this discussion
        > progresses, the current projects I see are summarized here:
        > http://www.pcgen-test.org
        > /wiki/index.php?title=Architecture_Changes_5.17

        Great detailed list there, certainly looks like lots of smaller items that code monkeys of all levels can dig into, I like.

        > <snip>
        >
        > However, significant work is still
        > required in order to take advantage of the type safety now
        > available in the core and truly improve performance. (I'll explain
        > more about this later as we get into potential projects for people)

        OK, I was gonna ask, but I'll wait :)

        > The interdependency between different parts of PCGen has been
        > partially addressed, especially with respect to the Token/Loader
        > System, but still has significant work remaining. The core and
        > output systems are still tightly linked. This can be easily
        > demonstrated as there are a number of output tokens that are
        > shipped with the core, rather than as plugins.

        Would this be a good project for someone wanting to get involved in the architecture put together a list like you did for splitting out the "Token/Loader System"? Not sure if there are other areas you'd like to see get fleshed out first.

        > This
        > interdependency between objects can be objectively measured through
        > the use of the acyclic dependency principle (which basically means
        > you want to avoid code cycles or tangles, depending on the terms
        > people prefer). The goal is to have a pure directed acyclic graph
        > of classes.

        For those who are interested, there is a tool called Jdepend which highlights these code cycles. IIRC it's one of the reports produced by our builds.

        > <snip>

        Thanks for kicking this off Tom!

        K
      • Tom Parker
        ... [Wiki changes for packages, etc.] I guess I ll leave that up to yourself and James to decide if that s useful/needful. I think it s a good idea.  I ll get
        Message 3 of 12 , Jun 16, 2009
        • 0 Attachment
          --- On Tue, 6/16/09, Martijn Verburg <martijnverburg@...> wrote:
          [Wiki changes for packages, etc.]

          I guess I'll leave that up to yourself and James to decide if that's useful/needful.

          I think it's a good idea.  I'll get a running "action/to still explain" list started on the Wiki so these things don't get lost.

          > The interdependency between different parts of PCGen has been
          > partially addressed, especially with respect to the Token/Loader
          > System, but still has significant work remaining.  The core and
          > output systems are still tightly linked.  This can be easily
          > demonstrated as there are a number of output tokens that are
          > shipped with the core, rather than as plugins.

          Would this be a good project for someone wanting to get involved in the architecture put together a list like you did for splitting out the "Token/Loader System"?  Not sure if there are other areas you'd like to see get fleshed out first.

          I think there are two good projects in the output system.

          First is ensuring the documentation is correct.  While this seems like a Doc function, it really requires someone to go through the code and validate that the code behavior matches what is documented.  I spent a lot of time on this for the PCC/LST system before we rebuilt the Token/Loader system, and it would be valuable to do the same on the output side before we attempt to rebuild it.

          The second is breaking out the items in the output system that need to be moved to plugins (the classes in pcgen.io.exporttoken), which is both creating the list (pretty trivial) and then backing up that list with concrete actions that need to take place in the code.  It's the second item that is complicated, and may have unique actions with each token.  It must not be assumed that the documentation is correct (unfortunately), so rip-and-repair is too dangerous.  Some of them (e.g. SkillToken) will be truly difficult and potentially require some major changes as our existing plugin system doesn't allow plugins to depend on each other.

          There is obviously a balance point here in explaining what needs to be done vs. simply doing it (if it's a simple change there's no need for a month of discussion), but I suspect some of these are non-trivial.  For documentation of what needs to be done, getting a handful of categories for the tokens (e.g. static call only, plugin dependency, etc.) to categorize the difficulty would be very helpful.  This is effectively what I did on the Token/Loader side with the early architecture documents.  It reduces to 5 types of loader tokens:

          (1) Primary Information Tokens with direct and simple information, e.g. SLOTS in Equipment
          (2) Link Tokens with relationships between objects, such as allows (LANGBONUS) or grants (ABILITY)
          (3) List Modification Tokens which define changes to base lists, such as SPELLLEVEL:CLASS and SPELLLEVEL:DOMAIN Tokens, which (surprise) modify SpellLists.
          (4) Replacement Tokens which are modifiers of some form, such as hit die locking [HITDIE in Templates] (which modifies the base hit die to a fixed value)
          (5) Factory tokens where the effects cannot be directly predicted when a token is created.  ADDLEVEL is a particular example here.

          As a side note that I'll cover more later, the true benefits of this breakout are not currently realized (we could have a separate list manager handle items in #3 and we could have a standardized Modifier system handle #4 and a standarized plugin application system that could handle #5).  We will get there, but need to handle the base issues in the core first before we finish the standardization (yet another topic for a later note)
           
          TP.
          --
          Tom Parker
          thpr@... and tppublic@...


        • Tom Parker
          ... For those who are interested, there is a tool called Jdepend which highlights these code cycles.  IIRC it s one of the reports produced by our builds.
          Message 4 of 12 , Jun 16, 2009
          • 0 Attachment
            --- On Tue, 6/16/09, Martijn Verburg <martijnverburg@...> wrote:
            > This
            > interdependency between objects can be objectively measured through
            > the use of the acyclic dependency principle (which basically means
            > you want to avoid code cycles or tangles, depending on the terms
            > people prefer).  The goal is to have a pure directed acyclic graph
            > of classes.

            For those who are interested, there is a tool called Jdepend which highlights these code cycles.  IIRC it's one of the reports produced by our builds.


            Should have added:

            SonarJ will also allow you to define dependency rules & enforce them.

            To add to the design concepts page on the Wiki that I originally pointed out, here is a good article:
            http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

            TP.
            --
            Tom Parker
            thpr@... and tppublic@...

          • Martijn Verburg
            Hi all, ... Is there someone in the team who wants to take a lead on this? If not I ll try to start something when I get back from my trip. It ll be more of a
            Message 5 of 12 , Jun 17, 2009
            • 0 Attachment
              Hi all,

              > I think there are two good projects in the output system.
              >
              > First is ensuring the documentation is correct.  While this seems
              > like a Doc function, it really requires someone to go through the
              > code and validate that the code behavior matches what is
              > documented.  I spent a lot of time on this for the PCC/LST system
              > before we rebuilt the Token/Loader system, and it would be valuable
              > to do the same on the output side before we attempt to rebuild it.
              >
              > The second is breaking out the items in the output system that need
              > to be moved to plugins (the classes in pcgen.io.exporttoken), which
              > is both creating the list (pretty trivial) and then backing up that
              > list with concrete actions that need to take place in the code. 
              > It's the second item that is complicated, and may have unique
              > actions with each token.  It must not be assumed that the
              > documentation is correct
              > (unfortunately), so rip-and-repair is too dangerous.  Some of them
              > (e.g. SkillToken) will be truly difficult and potentially
              > require some major changes as our existing plugin system doesn't
              > allow plugins to depend on each other.
              >
              > There is obviously a balance point here in explaining what needs to
              > be done vs. simply doing it (if it's a simple change there's no
              > need for a month of discussion), but I suspect some of these are
              > non-trivial.  For documentation of what needs to be done, getting a
              > handful of categories for the tokens (e.g. static call only, plugin
              > dependency, etc.) to categorize the difficulty would be very
              > helpful.

              Is there someone in the team who wants to take a lead on this?

              If not I'll try to start something when I get back from my trip. It'll be more of a worker bee effort than an architecture effort though e.g. I'll start by marrying up the OS tokens and the docs since I'm familiarish with that code and I can more or less make my way around the Output sheets themselves.

              K
            • Andrew Maitland
              Just a note, Tom s Arch To Do list is now up on the WIKI, under the main ARCH page near the bottom. For a direct link try this:
              Message 6 of 12 , Jun 17, 2009
              • 0 Attachment
                Just a note, Tom's Arch To Do list is now up on the WIKI, under the main ARCH page near the bottom. For a direct link try this:

                http://www.pcgen-test.org/wiki/index.php?title=Tom%27s_Arch_%22TO_DO%22_List
                Andrew Maitland (LegacyKing)
                Admin Silverback, PCGen Board of Directors 
                Data Chimp, Docs Tamarin
                Unique Title "Quick-Silverback Tracker Monkey"


                Martijn Verburg wrote:

                Hi all,

                > I think there are two good projects in the output system.
                >
                > First is ensuring the documentation is correct.  While this seems
                > like a Doc function, it really requires someone to go through the
                > code and validate that the code behavior matches what is
                > documented.  I spent a lot of time on this for the PCC/LST system
                > before we rebuilt the Token/Loader system, and it would be valuable
                > to do the same on the output side before we attempt to rebuild it.
                >
                > The second is breaking out the items in the output system that need
                > to be moved to plugins (the classes in pcgen.io.exporttoke n), which
                > is both creating the list (pretty trivial) and then backing up that
                > list with concrete actions that need to take place in the code. 
                > It's the second item that is complicated, and may have unique
                > actions with each token.  It must not be assumed that the
                > documentation is correct
                > (unfortunately) , so rip-and-repair is too dangerous.  Some of them
                > (e.g. SkillToken) will be truly difficult and potentially
                > require some major changes as our existing plugin system doesn't
                > allow plugins to depend on each other.
                >
                > There is obviously a balance point here in explaining what needs to
                > be done vs. simply doing it (if it's a simple change there's no
                > need for a month of discussion), but I suspect some of these are
                > non-trivial.  For documentation of what needs to be done, getting a
                > handful of categories for the tokens (e.g. static call only, plugin
                > dependency, etc.) to categorize the difficulty would be very
                > helpful.

                Is there someone in the team who wants to take a lead on this?

                If not I'll try to start something when I get back from my trip. It'll be more of a worker bee effort than an architecture effort though e.g. I'll start by marrying up the OS tokens and the docs since I'm familiarish with that code and I can more or less make my way around the Output sheets themselves.

                K

              • Martijn Verburg
                Hi all, ... I m starting this as of today, it s going to be a long task :). If anybody else is interested in the OS Token area of PCGen then please let
                Message 7 of 12 , Aug 18, 2009
                • 0 Attachment
                  Hi all,

                  <snip>

                  > Is there someone in the team who wants to take a lead on this?
                  >
                  > If not I'll try to start something when I get back from my trip.
                  > It'll be more of a worker bee effort than an architecture effort
                  > though e.g. I'll start by marrying up the OS tokens and the docs
                  > since I'm familiarish with that code and I can more or less make my
                  > way around the Output sheets themselves.

                  I'm starting this as of today, it's going to be a long task :). If anybody else is interested in the OS Token area of PCGen then please let me know.

                  K
                • Andrew Maitland
                  ... I have no idea of how they work. But thank you for jumping on this. I believe this is the first step Tom P. wanted before we can evaluate FreeMarker vs.
                  Message 8 of 12 , Aug 18, 2009
                  • 0 Attachment
                    Martijn Verburg wrote:
                    >
                    >
                    > Hi all,
                    >
                    > <snip>
                    >
                    >> Is there someone in the team who wants to take a lead on this?
                    >>
                    >> If not I'll try to start something when I get back from my
                    trip.
                    >> It'll be more of a worker bee effort than an architecture
                    effort
                    >> though e.g. I'll start by marrying up the OS tokens and the
                    docs
                    >> since I'm familiarish with that code and I can more or less
                    make my
                    >>  way around the Output sheets themselves.
                    >
                    > I'm starting this as of today, it's going to be a long task :). If
                    > anybody else is interested in the OS Token area of PCGen then
                    please
                    > let me know.

                    I have no idea of how they work. But thank you for jumping on this. I believe this is the first step Tom P. wanted before we can evaluate FreeMarker vs. Velocity for revamping the Output Sheets.
                    >
                    > K
                    >
                    > <!-- #ygrp-mkp{ border: 1px solid #d8d8d8;
                    font-family:
                    > Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
                    > 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
                    > font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
                    > #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; }
                    #ygrp-mkp
                    > .ad a{ color: #0000ff; text-decoration: none; } --> <!--
                    > #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor
                    #ygrp-lc
                    > #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
                    > line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:
                    10px;
                    > padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px;
                    font-family:
                    > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
                    > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg
                    select,
                    > input, textarea {font:99% arial,helvetica,clean,sans-serif;}
                    > #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
                    > #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:
                    Georgia;
                    > } #ygrp-text p{ margin: 0 0 1em 0; } dd.last p a { font-family:
                    > Verdana; font-weight: bold; } #ygrp-vitnav{ padding-top: 10px;
                    > font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
                    > padding: 0 1px; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
                    > #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
                    > #reco-head { font-weight: bold; color: #ff7900; } #reco-category{
                    > font-size: 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital a{
                    > text-decoration: none; } #ygrp-vital a:hover{ text-decoration:
                    > underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; }
                    > #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px 0;
                    > font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
                    > font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
                    > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding:
                    > 8px 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight:
                    > bold; color: #628c2a; font-size: 100%; line-height: 122%; }
                    > #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
                    > a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:
                    > 0; font-weight: normal; color: #000000; } o{font-size: 0; }
                    > .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
                    > blockquote{margin: 0 0 0 4px;} .replbq{margin:4} dd.last p span {
                    > margin-right: 10px; font-family: Verdana; font-weight: bold; }
                    > dd.last p span.yshortcuts { margin-right: 0; } div.photo-title a,
                    > div.photo-title a:active, div.photo-title a:hover, div.photo-title
                    > a:visited { text-decoration: none; } div.file-title a,
                    div.file-title
                    > a:active, div.file-title a:hover, div.file-title a:visited {
                    > text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
                    > padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count
                    > span { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg
                    #ygrp-msg
                    > p a span.yshortcuts { font-family: Verdana; font-size: 10px;
                    > font-weight: normal; } #ygrp-msg p a { font-family: Verdana; }
                    > #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div div a {
                    > text-decoration: none; } div.attach-table { width: 400px; } -->


                    --

                    Andrew Maitland (LegacyKing)
                    Admin Silverback, PCGen Board of Directors
                    Data Chimp, Docs Tamarin
                    Unique Title "Quick-Silverback Tracker Monkey"

                  • James Dempsey
                    Hi Kar, On 18/08/2009 11:46 PM Martijn Verburg wrote ... This is an area which I have an interest in and would be happy to lend a hand. Cheers, James.
                    Message 9 of 12 , Aug 18, 2009
                    • 0 Attachment
                      Hi Kar,

                      On 18/08/2009 11:46 PM Martijn Verburg wrote
                      > Hi all,
                      >
                      > <snip>
                      >
                      >
                      >> Is there someone in the team who wants to take a lead on this?
                      >>
                      >> If not I'll try to start something when I get back from my trip.
                      >> It'll be more of a worker bee effort than an architecture effort
                      >> though e.g. I'll start by marrying up the OS tokens and the docs
                      >> since I'm familiarish with that code and I can more or less make my
                      >> way around the Output sheets themselves.
                      >>
                      >
                      > I'm starting this as of today, it's going to be a long task :). If anybody else is interested in the OS Token area of PCGen then please let me know.
                      >
                      >
                      This is an area which I have an interest in and would be happy to lend a
                      hand.

                      Cheers,
                      James.
                    • Martijn Verburg
                      Hi James/All, ... Cool, didn t expect to get the Code SB in to help, certainly doesn t hurt! :) OK, so basically I m starting by going through the documented
                      Message 10 of 12 , Aug 19, 2009
                      • 0 Attachment
                        Hi James/All,

                        > > I'm starting this as of today, it's going to be a long task :).
                        > > If anybody else is interested in the OS Token area of PCGen then
                        > > please let me know.
                        > >
                        > This is an area which I have an interest in and would be happy to
                        > lend a hand.

                        Cool, didn't expect to get the Code SB in to help, certainly doesn't hurt! :)

                        OK, so basically I'm starting by going through the documented tags starting at ABILITY and going down in the Alphabet.

                        I've started a troubleshooting2.htm character sheet (will check in shortly) which simply lists out Token/Value pairs (including all of the variants for that token, e.g. ATTACK.RANGED.TOTAL).

                        That allows me to perform a basic check to make sure that the tokens are parsing their various options correctly and are producing correct values (I'm building several test characters for this).

                        I then look at the source code of that token to see if there are any other pathways that the docs miss or any other gotchas. I also tend to tidy up the token and its use cases if possible along the way.

                        It's a slow process, but as Tom said, we need to know our base line is accurate before we start doing any 'real' work.

                        Does that sound reasonable to you? If so I was thinking you could start at the other end of the Alphabet and we'd meet in the middle at some stage in the future.

                        K
                      • thpr
                        ... Given today s activity, is your intent to clean up the Javadocs or the published HTML docs? I am far more concerned about the HTML docs, and as far as
                        Message 11 of 12 , Aug 19, 2009
                        • 0 Attachment
                          --- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...> wrote:
                          > I'm starting this as of today, it's going to be a long task :). If anybody else is interested in the OS Token area of PCGen then please let me know.


                          Given today's activity, is your intent to clean up the Javadocs or the published HTML docs? I am far more concerned about the HTML docs, and as far as progress toward redoing the output system, I think that is vastly more important than code cleanup. In particular, I'm unsure of the life span of the output token code, as some functions will be subsumed into the facets, and James will have to provide guidance on what a templating engine would do to the remaining token code. Thus, I'm unsure how much effort you want to put into the code and Javadocs. YMMV.

                          TP.
                        • karianna03
                          Hi Tom, ... The HTML docs are the primary focus, but I ll also tidy up some of the Javadoc etc when I feel it is warranted. Usually when I don t understand a
                          Message 12 of 12 , Aug 20, 2009
                          • 0 Attachment
                            Hi Tom,

                            > Given today's activity, is your intent to clean up the Javadocs or
                            > the published HTML docs? I am far more concerned about the HTML
                            > docs, and as far as progress toward redoing the output system, I
                            > think that is vastly more important than code cleanup. In
                            > particular, I'm unsure of the life span of the output token code,
                            > as some functions will be subsumed into the facets, and James will
                            > have to provide guidance on what a templating engine would do to the
                            > remaining token code. Thus, I'm unsure how much effort you want to
                            > put into the code and Javadocs. YMMV.

                            The HTML docs are the primary focus, but I'll also tidy up some of the Javadoc etc when I feel it is warranted. Usually when I don't understand a concept in PCGen (which is almost all of the time in our code base ;p) I comment the crap out of it and use that as a reference to go back to. The 'caching' concept in the AbilityToken is an example of this, I'll comment it deeply in that class, but won't bother elsewhere - I'll have my example by then).

                            K
                          Your message has been successfully submitted and would be delivered to recipients shortly.