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

Facet Organization

Expand Messages
  • thpr
    Okay, another discussion topic of moving things around. We ve progressed down the path of having facets as the core processors of changes to a
    Message 1 of 16 , Feb 8, 2012
    • 0 Attachment
      Okay, another discussion topic of moving things around.

      We've progressed down the path of having facets as the core "processors" of changes to a PlayerCharacter, and as a result, we have a LOT of them. (see pcgen.cdom.facet) It's time for some organization.

      There are (at least) two ways of organizing this, and I think I propose we do it by behavior.

      We could do it by function (those that do things with abilities, those related to alignment, etc.), but I'm concerned that would have a lot of cross-behavior issues, and we really don't have any of the other code organized that way, so I think it would be confusing.

      So in general there are a few behaviors of facets:
      (1) Event facets. These take input of something that has changed on a PC... such as adding a new piece of user equipment. This will trigger a set of events that go through the...
      (2) Filter Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
      (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
      (4) Action Facets: These facets perform certain calculations that are relevant to PC behavior (e.g. calculating the # of hands). These facets, as well as the base facets are listened to by...
      (5) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.

      How do you distinguish Action and Display? Action facets will be listened to by event, filter, or base facets in some way (they cycle back into the active parts of the core that are required to "do something"). Display facets never feed anything except the UI or output tokens (or - today anyway - the PCG file)

      How do you distinguish Event and Filter facets? Basically function. Filter facets perform a basic consolidation. They are not reading variables from the CDOMObject to extract a BONUS or check for ADD:, they are either performing a dumb consolidation or they are checking for prerequisites.

      So with that, I have 6 packages (the 5 above plus "base" to handle some common stuff)
      pcgen.cdom.facet.action
      pcgen.cdom.facet.base
      pcgen.cdom.facet.display
      pcgen.cdom.facet.filter
      pcgen.cdom.facet.event
      pcgen.cdom.facet.base

      Thoughts?

      TP.
    • Devon Jones
      Sounds good to me, much easier to understand. This also suggests that you should not have any facets that meet more then one of those qualities, which
      Message 2 of 16 , Feb 8, 2012
      • 0 Attachment
        Sounds good to me, much easier to understand.  This also suggests that you should not have any facets that meet more then one of those qualities, which suggests to me that we actually want to make a base class for each facet type so a facet can only subclass one of them. (unless of course, we have done this ;) )

        Devon

        On Wed, Feb 8, 2012 at 5:59 PM, thpr <thpr@...> wrote:
         

        Okay, another discussion topic of moving things around.

        We've progressed down the path of having facets as the core "processors" of changes to a PlayerCharacter, and as a result, we have a LOT of them. (see pcgen.cdom.facet) It's time for some organization.

        There are (at least) two ways of organizing this, and I think I propose we do it by behavior.

        We could do it by function (those that do things with abilities, those related to alignment, etc.), but I'm concerned that would have a lot of cross-behavior issues, and we really don't have any of the other code organized that way, so I think it would be confusing.

        So in general there are a few behaviors of facets:
        (1) Event facets. These take input of something that has changed on a PC... such as adding a new piece of user equipment. This will trigger a set of events that go through the...
        (2) Filter Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
        (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
        (4) Action Facets: These facets perform certain calculations that are relevant to PC behavior (e.g. calculating the # of hands). These facets, as well as the base facets are listened to by...
        (5) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.

        How do you distinguish Action and Display? Action facets will be listened to by event, filter, or base facets in some way (they cycle back into the active parts of the core that are required to "do something"). Display facets never feed anything except the UI or output tokens (or - today anyway - the PCG file)

        How do you distinguish Event and Filter facets? Basically function. Filter facets perform a basic consolidation. They are not reading variables from the CDOMObject to extract a BONUS or check for ADD:, they are either performing a dumb consolidation or they are checking for prerequisites.

        So with that, I have 6 packages (the 5 above plus "base" to handle some common stuff)
        pcgen.cdom.facet.action
        pcgen.cdom.facet.base
        pcgen.cdom.facet.display
        pcgen.cdom.facet.filter
        pcgen.cdom.facet.event
        pcgen.cdom.facet.base

        Thoughts?

        TP.


      • Tom Parker
        There is not a single base class for each of these today.  I m not sure that s really necessary or useful, since the base classes would be empty... so it s
        Message 3 of 16 , Feb 8, 2012
        • 0 Attachment

          There is not a single base class for each of these today.  I'm not sure that's really necessary or useful, since the base classes would be empty... so it's only a tag.  Also, I think it might be counter-productive to the structure we have today because right now there are some things we can share (such as firing an event when the internal list is changed) that is common between some of these classes.  So I think this requires thought as to having a base class and the resulting impact...

          Open to comments on that, but I'm inclined against it at the moment.

          TP.


          From: Devon Jones <devon.jones@...>
          To: pcgen_developers@yahoogroups.com
          Sent: Wednesday, February 8, 2012 6:04 PM
          Subject: Re: [pcgen_developers] Facet Organization



          Sounds good to me, much easier to understand.  This also suggests that you should not have any facets that meet more then one of those qualities, which suggests to me that we actually want to make a base class for each facet type so a facet can only subclass one of them. (unless of course, we have done this ;) )

          Devon

          On Wed, Feb 8, 2012 at 5:59 PM, thpr <thpr@...> wrote:
           
          Okay, another discussion topic of moving things around.

          We've progressed down the path of having facets as the core "processors" of changes to a PlayerCharacter, and as a result, we have a LOT of them. (see pcgen.cdom.facet) It's time for some organization.

          There are (at least) two ways of organizing this, and I think I propose we do it by behavior.

          We could do it by function (those that do things with abilities, those related to alignment, etc.), but I'm concerned that would have a lot of cross-behavior issues, and we really don't have any of the other code organized that way, so I think it would be confusing.

          So in general there are a few behaviors of facets:
          (1) Event facets. These take input of something that has changed on a PC... such as adding a new piece of user equipment. This will trigger a set of events that go through the...
          (2) Filter Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
          (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
          (4) Action Facets: These facets perform certain calculations that are relevant to PC behavior (e.g. calculating the # of hands). These facets, as well as the base facets are listened to by...
          (5) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.

          How do you distinguish Action and Display? Action facets will be listened to by event, filter, or base facets in some way (they cycle back into the active parts of the core that are required to "do something"). Display facets never feed anything except the UI or output tokens (or - today anyway - the PCG file)

          How do you distinguish Event and Filter facets? Basically function. Filter facets perform a basic consolidation. They are not reading variables from the CDOMObject to extract a BONUS or check for ADD:, they are either performing a dumb consolidation or they are checking for prerequisites.

          So with that, I have 6 packages (the 5 above plus "base" to handle some common stuff)
          pcgen.cdom.facet.action
          pcgen.cdom.facet.base
          pcgen.cdom.facet.display
          pcgen.cdom.facet.filter
          pcgen.cdom.facet.event
          pcgen.cdom.facet.base

          Thoughts?

          TP.






        • Devon Jones
          Ok, or requiting an interface for each of these, so it s clear which is implemented. Devon
          Message 4 of 16 , Feb 8, 2012
          • 0 Attachment
            Ok, or requiting an interface for each of these, so it's clear which is implemented.

            Devon

            On Wed, Feb 8, 2012 at 6:11 PM, Tom Parker <thpr@...> wrote:
             


            There is not a single base class for each of these today.  I'm not sure that's really necessary or useful, since the base classes would be empty... so it's only a tag.  Also, I think it might be counter-productive to the structure we have today because right now there are some things we can share (such as firing an event when the internal list is changed) that is common between some of these classes.  So I think this requires thought as to having a base class and the resulting impact...

            Open to comments on that, but I'm inclined against it at the moment.

            TP.


            From: Devon Jones <devon.jones@...>
            To: pcgen_developers@yahoogroups.com
            Sent: Wednesday, February 8, 2012 6:04 PM
            Subject: Re: [pcgen_developers] Facet Organization



            Sounds good to me, much easier to understand.  This also suggests that you should not have any facets that meet more then one of those qualities, which suggests to me that we actually want to make a base class for each facet type so a facet can only subclass one of them. (unless of course, we have done this ;) )

            Devon

            On Wed, Feb 8, 2012 at 5:59 PM, thpr <thpr@...> wrote:
             
            Okay, another discussion topic of moving things around.

            We've progressed down the path of having facets as the core "processors" of changes to a PlayerCharacter, and as a result, we have a LOT of them. (see pcgen.cdom.facet) It's time for some organization.

            There are (at least) two ways of organizing this, and I think I propose we do it by behavior.

            We could do it by function (those that do things with abilities, those related to alignment, etc.), but I'm concerned that would have a lot of cross-behavior issues, and we really don't have any of the other code organized that way, so I think it would be confusing.

            So in general there are a few behaviors of facets:
            (1) Event facets. These take input of something that has changed on a PC... such as adding a new piece of user equipment. This will trigger a set of events that go through the...
            (2) Filter Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
            (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
            (4) Action Facets: These facets perform certain calculations that are relevant to PC behavior (e.g. calculating the # of hands). These facets, as well as the base facets are listened to by...
            (5) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.

            How do you distinguish Action and Display? Action facets will be listened to by event, filter, or base facets in some way (they cycle back into the active parts of the core that are required to "do something"). Display facets never feed anything except the UI or output tokens (or - today anyway - the PCG file)

            How do you distinguish Event and Filter facets? Basically function. Filter facets perform a basic consolidation. They are not reading variables from the CDOMObject to extract a BONUS or check for ADD:, they are either performing a dumb consolidation or they are checking for prerequisites.

            So with that, I have 6 packages (the 5 above plus "base" to handle some common stuff)
            pcgen.cdom.facet.action
            pcgen.cdom.facet.base
            pcgen.cdom.facet.display
            pcgen.cdom.facet.filter
            pcgen.cdom.facet.event
            pcgen.cdom.facet.base

            Thoughts?

            TP.







          • javydreamer
            Hope you guys don t bother with my comments, me being just an user wanting to use your code as libraries. The work looks amazing, working towards a scenario
            Message 5 of 16 , Feb 9, 2012
            • 0 Attachment
              Hope you guys don't bother with my comments, me being just an user wanting to use your code as libraries.

              The work looks amazing, working towards a scenario for being used as a library.

              What would be the correct interface point to work with PCGen as a library, directly to the facets or is there a plan of an utility type class for each of the major functions?
            • Tom Parker
              I don t know about utility type class for each of the major functions - that alone is a bit of a loaded analysis in defining what the functions are - but the
              Message 6 of 16 , Feb 9, 2012
              • 0 Attachment
                I don't know about utility type class for each of the major functions - that alone is a bit of a loaded analysis in defining what the functions are - but the intent is to have an "output" layer that specifically identifies what folks should use to access information.  The more you interact with the facets, the more you will encounter problems when "the core" exercises the right to rewire behavior while keeping the external interface consistent.

                I anticipate two different interfaces (note: I don't necessarily literally mean a Java Interface, though it might be, also don't necessarily mean two is only two files, it is rather two groupings of behavior):
                1) Output
                2) Input/Commands

                #1 will happen first (you can see another thread talking about cleanup of PlayerCharacter).  This will provide a consistent method of getting at information - so hopefully the new UI, the output tokens, and other things trying to extract information from the core has one place to go. 

                #2 will come later, and there will be good reasons there to stay insulated from the facets as well.  Truth in disclosure: This is not likely to be a 2012 project.

                For now, most (all?) of what you would need has been demonstrated by the new UI behaviors and how it consolidates the access points to the core down to a reasonably "small" set of behaviors (the facades).  Over time, I anticipate some of these behaviors will be moved or consolidated to other places, but generally the framework is already there if not as clearly broken out as we want it to be.

                TP.


                From: javydreamer <javier.ortiz.78@...>
                To: pcgen_developers@yahoogroups.com
                Sent: Thursday, February 9, 2012 8:00 AM
                Subject: [pcgen_developers] Re: Facet Organization

                Hope you guys don't bother with my comments, me being just an user wanting to use your code as libraries.

                The work looks amazing, working towards a scenario for being used as a library.

                What would be the correct interface point to work with PCGen as a library, directly to the facets or is there a plan of an utility type class for each of the major functions?


              • javydreamer
                Thanks for the update. That s great news! I guess that my issue finding the code is due to all the abstraction used within the system to suite all sources. I
                Message 7 of 16 , Feb 9, 2012
                • 0 Attachment
                  Thanks for the update. That's great news!

                  I guess that my issue finding the code is due to all the abstraction used within the system to suite all sources. I just can't figure out where to start. That's what I think is the missing documentation.

                  I'll take this to a different thread. Thanks!
                • thpr
                  Looking through this further and now playing with some sample moves to see how well this works, I m going to tweak and clarify this proposal a bit: (1) Input
                  Message 8 of 16 , Feb 9, 2012
                  • 0 Attachment
                    Looking through this further and now playing with some sample moves to see how well this works, I'm going to tweak and clarify this proposal a bit:

                    (1) Input facets. These take input of something that has changed on a PC that will trigger a model change... such as adding a new piece of user equipment. This will trigger a set of events that may go right to the model or may go through the...

                    (2) Link Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...

                    (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...

                    (4) Filter Facets: These facets reduce down the model facets into certain types of objects (e.g. just Natural Equipment) or consolidate them together into one big group (e.g. all objects granted to the PC). This can be used by

                    (4) Action Facets: These facets look INTO the CDOMObjects and perform certain calculations that are relevant to PC behavior (e.g. triggering behavior from an ADD:). There are two groups of Action Facets: Global and Local. Often these facets will feed information (on things granted) into a filter or model facet. These facets, as well as the model and filter facets are listened to by display facets.

                    (5) Analysis Facets: These facets look at CDOMObjects and perform calculations based on that information, e.g. calculating the number of hands. This are also often used by...

                    (6) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.

                    We also have:

                    (7) Utility Facets: General overall things that don't fit elsewhere (Prerequisite testing, formula resolving)

                    (8) Fact facets: These facets don't impact the model directly, but handle things that the user can modify (e.g. character age), and are NOT CDOMObject. (These objects cannot grant other objects)

                    How do you distinguish an ___ facet?

                    (1) Input facets are typically called directly from PlayerCharacter and are a "pass through" for a user action in the UI. However, they are NOT serving as a model facet (or they would be there), as they require some form of consolidation in order for all of the objects of that given type to get into the model. Example is UserEquipmentFacet.
                    (2) Link Facets consolidate things from input facets or data from action facets and put them into the "pipeline" to reach the model. Generally these are "pass through", although they may test prerequisites. An example is ConditionallyGrantedAbilityFacet
                    (3) Model facets are the "core" objects for each of the CDOMObjects. They are unlikely to have any local fields (any listening or listeners is set up by other facets). They must store CDOMObjects or some near derivative (e.g. SheildProfProvider). An example is RaceFacet.
                    (4) Action Facets operate on the contents (key behavior is keying into the object to look at things set in the LST) of a granted object to potentially do additional granting. Example is AutoLanguageFacet (which reacts to AUTO:LANGUAGE token being present on a granted object)
                    (5) Analysis Facets compare information from different facets to produce a piece of information. Rarely do they store information, and if they do it must only be a cache. Generally these are polled (display or other places pull information from these facets - they do not throw events). Example is HandsFacet.
                    (6) Display Facets just produce output. I'm not actually sure we have any of these right now :)
                    (7) Utility Facets serve an overall utility to other facets, such as resolving a formula, but do not serve a model, filtering, or other function. They should be stateless.
                    (8) Fact facets are the other persistent piece of a PlayerCharacter other than the ModelFacets. These hold simple (non-CDOMObject) pieces of information, like the character age. These could be things that feed back into the core (age is one example due to Stat changes), but they don't have to be (Birthday does not, for example). FactFacet and AgeFacet are examples of Fact Facts.

                    We maintain "base" as the place for the abstract facet foundation for the other packages...

                    So with that, I have the following packages
                    pcgen.cdom.facet.action_global
                    pcgen.cdom.facet.action_local
                    pcgen.cdom.facet.analysis
                    pcgen.cdom.facet.analysis_cached
                    pcgen.cdom.facet.base
                    pcgen.cdom.facet.display
                    pcgen.cdom.facet.fact
                    pcgen.cdom.facet.filter
                    pcgen.cdom.facet.input
                    pcgen.cdom.facet.model
                    pcgen.cdom.facet.utility

                    Open to input, I probably won't do this for a bit since I want to get a few more things into facets in preparation for this redo.

                    Note also to Devon's point about "A Facet shouldn't do more than one of these" - we have a few today that start to stretch these definitions, and it'll probably make sense to break them up into two facets.

                    One thing I don't intend to do is break apart link facets. Some of those can both listen and store and push events on changes, and I think that makes sense all in one place rather than arbitrarily forcing the listening/analysis to happen in one facet which directly writes to another. MAYBE at some point some code consolidation can be done with that change, but that's pretty fine polishing to be worried about right now.

                    TP.
                  • James Dempsey
                    Hi Tom, This looks great. It seems a logical break-down of the many facets and will help in understanding them I think. This would also be great as package
                    Message 9 of 16 , Feb 10, 2012
                    • 0 Attachment
                      Hi Tom,

                      This looks great. It seems a logical break-down of the many facets and
                      will help in understanding them I think. This would also be great as
                      package javadoc in pcgen.cdom.facet.

                      In my best 'boat shed' contribution though, should we have underscores
                      in package names?

                      Oh and how does a global action facet differ from a local action facet?

                      Cheers,
                      James.

                      On 10/02/2012 11:52 AM thpr wrote
                      > Looking through this further and now playing with some sample moves to see how well this works, I'm going to tweak and clarify this proposal a bit:
                      >
                      > (1) Input facets. These take input of something that has changed on a PC that will trigger a model change... such as adding a new piece of user equipment. This will trigger a set of events that may go right to the model or may go through the...
                      >
                      > (2) Link Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
                      >
                      > (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
                      >
                      > (4) Filter Facets: These facets reduce down the model facets into certain types of objects (e.g. just Natural Equipment) or consolidate them together into one big group (e.g. all objects granted to the PC). This can be used by
                      >
                      > (4) Action Facets: These facets look INTO the CDOMObjects and perform certain calculations that are relevant to PC behavior (e.g. triggering behavior from an ADD:). There are two groups of Action Facets: Global and Local. Often these facets will feed information (on things granted) into a filter or model facet. These facets, as well as the model and filter facets are listened to by display facets.
                      >
                      > (5) Analysis Facets: These facets look at CDOMObjects and perform calculations based on that information, e.g. calculating the number of hands. This are also often used by...
                      >
                      > (6) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.
                      >
                      > We also have:
                      >
                      > (7) Utility Facets: General overall things that don't fit elsewhere (Prerequisite testing, formula resolving)
                      >
                      > (8) Fact facets: These facets don't impact the model directly, but handle things that the user can modify (e.g. character age), and are NOT CDOMObject. (These objects cannot grant other objects)
                      >
                      > How do you distinguish an ___ facet?
                      >
                      > (1) Input facets are typically called directly from PlayerCharacter and are a "pass through" for a user action in the UI. However, they are NOT serving as a model facet (or they would be there), as they require some form of consolidation in order for all of the objects of that given type to get into the model. Example is UserEquipmentFacet.
                      > (2) Link Facets consolidate things from input facets or data from action facets and put them into the "pipeline" to reach the model. Generally these are "pass through", although they may test prerequisites. An example is ConditionallyGrantedAbilityFacet
                      > (3) Model facets are the "core" objects for each of the CDOMObjects. They are unlikely to have any local fields (any listening or listeners is set up by other facets). They must store CDOMObjects or some near derivative (e.g. SheildProfProvider). An example is RaceFacet.
                      > (4) Action Facets operate on the contents (key behavior is keying into the object to look at things set in the LST) of a granted object to potentially do additional granting. Example is AutoLanguageFacet (which reacts to AUTO:LANGUAGE token being present on a granted object)
                      > (5) Analysis Facets compare information from different facets to produce a piece of information. Rarely do they store information, and if they do it must only be a cache. Generally these are polled (display or other places pull information from these facets - they do not throw events). Example is HandsFacet.
                      > (6) Display Facets just produce output. I'm not actually sure we have any of these right now :)
                      > (7) Utility Facets serve an overall utility to other facets, such as resolving a formula, but do not serve a model, filtering, or other function. They should be stateless.
                      > (8) Fact facets are the other persistent piece of a PlayerCharacter other than the ModelFacets. These hold simple (non-CDOMObject) pieces of information, like the character age. These could be things that feed back into the core (age is one example due to Stat changes), but they don't have to be (Birthday does not, for example). FactFacet and AgeFacet are examples of Fact Facts.
                      >
                      > We maintain "base" as the place for the abstract facet foundation for the other packages...
                      >
                      > So with that, I have the following packages
                      > pcgen.cdom.facet.action_global
                      > pcgen.cdom.facet.action_local
                      > pcgen.cdom.facet.analysis
                      > pcgen.cdom.facet.analysis_cached
                      > pcgen.cdom.facet.base
                      > pcgen.cdom.facet.display
                      > pcgen.cdom.facet.fact
                      > pcgen.cdom.facet.filter
                      > pcgen.cdom.facet.input
                      > pcgen.cdom.facet.model
                      > pcgen.cdom.facet.utility
                      >
                      > Open to input, I probably won't do this for a bit since I want to get a few more things into facets in preparation for this redo.
                      >
                      > Note also to Devon's point about "A Facet shouldn't do more than one of these" - we have a few today that start to stretch these definitions, and it'll probably make sense to break them up into two facets.
                      >
                      > One thing I don't intend to do is break apart link facets. Some of those can both listen and store and push events on changes, and I think that makes sense all in one place rather than arbitrarily forcing the listening/analysis to happen in one facet which directly writes to another. MAYBE at some point some code consolidation can be done with that change, but that's pretty fine polishing to be worried about right now.
                      >
                      > TP.
                    • Tom Parker
                      So I used those package names with underscores because I don t recall seeing package names with capitals (or if so very rare) and I was trying to keep local
                      Message 10 of 16 , Feb 10, 2012
                      • 0 Attachment

                        So I used those package names with underscores because I don't recall seeing package names with capitals (or if so very rare) and I was trying to keep local and global actions near each other for display purposes.  We can do globalactions and localactions if that's better.

                        As far as global and local actions, it's directly parallel to global and local tokens.  So Template's FEAT (which drives a selection and grants it) would be a localaction to react to that, while the facet that reacts to say, AUTO:LANGUAGE would be a globalaction.

                        I guess that's somewhat arbitrary, and given that some of our global tokens aren't so global (See my recent post on _exp about removing some ambiguous capabilities) it may be best to avoid this distinction anyway.

                        TP.


                        From: James Dempsey <jdempsey@...>
                        To: pcgen_developers@yahoogroups.com
                        Sent: Friday, February 10, 2012 3:42 AM
                        Subject: Re: [pcgen_developers] Re: Facet Organization

                        Hi Tom,

                        This looks great. It seems a logical break-down of the many facets and
                        will help in understanding them I think. This would also be great as
                        package javadoc in pcgen.cdom.facet.

                        In my best 'boat shed' contribution  though, should we have underscores
                        in package names?

                        Oh and how does a global action facet differ from a local action facet?

                        Cheers,
                        James.

                        On 10/02/2012 11:52 AM thpr wrote
                        > Looking through this further and now playing with some sample moves to see how well this works, I'm going to tweak and clarify this proposal a bit:
                        >
                        > (1) Input facets. These take input of something that has changed on a PC that will trigger a model change... such as adding a new piece of user equipment. This will trigger a set of events that may go right to the model or may go through the...
                        >
                        > (2) Link Facets. These take a certain type of object, and consolidate them down (or
                        filter out those the PC is not qualified to have) and store the results into the...
                        >
                        > (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
                        >
                        > (4) Filter Facets: These facets reduce down the model facets into certain types of objects (e.g. just Natural Equipment) or consolidate them together into one big group (e.g. all objects granted to the PC).  This can be used by
                        >
                        > (4) Action Facets: These facets look INTO the CDOMObjects and perform certain calculations that are relevant to PC behavior (e.g. triggering behavior from an ADD:). There are two groups of Action Facets: Global and Local.  Often these facets will feed information (on things granted) into a filter or model facet.  These facets, as well as the model and filter facets
                        are listened to by display facets.
                        >
                        > (5) Analysis Facets: These facets look at CDOMObjects and perform calculations based on that information, e.g. calculating the number of hands.  This are also often used by...
                        >
                        > (6) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.
                        >
                        > We also have:
                        >
                        > (7) Utility Facets: General overall things that don't fit elsewhere (Prerequisite testing, formula resolving)
                        >
                        > (8) Fact facets: These facets don't impact the model directly, but handle things that the user can modify (e.g. character age), and are NOT CDOMObject.  (These objects cannot grant other objects)
                        >
                        > How do you distinguish an ___ facet?
                        >
                        > (1) Input facets are typically called directly from PlayerCharacter and are a "pass through" for a
                        user action in the UI.  However, they are NOT serving as a model facet (or they would be there), as they require some form of consolidation in order for all of the objects of that given type to get into the model.  Example is UserEquipmentFacet.
                        > (2) Link Facets consolidate things from input facets or data from action facets and put them into the "pipeline" to reach the model.  Generally these are "pass through", although they may test prerequisites.  An example is ConditionallyGrantedAbilityFacet
                        > (3) Model facets are the "core" objects for each of the CDOMObjects.  They are unlikely to have any local fields (any listening or listeners is set up by other facets).  They must store CDOMObjects or some near derivative (e.g. SheildProfProvider).  An example is RaceFacet.
                        > (4) Action Facets operate on the contents (key behavior is keying into the object to look at things set in the LST) of a granted
                        object to potentially do additional granting.  Example is AutoLanguageFacet (which reacts to AUTO:LANGUAGE token being present on a granted object)
                        > (5) Analysis Facets compare information from different facets to produce a piece of information. Rarely do they store information, and if they do it must only be a cache.  Generally these are polled (display or other places pull information from these facets - they do not throw events).  Example is HandsFacet.
                        > (6) Display Facets just produce output.  I'm not actually sure we have any of these right now :)
                        > (7) Utility Facets serve an overall utility to other facets, such as resolving a formula, but do not serve a model, filtering, or other function.  They should be stateless.
                        > (8) Fact facets are the other persistent piece of a PlayerCharacter other than the ModelFacets.  These hold simple (non-CDOMObject) pieces of information, like the character
                        age.  These could be things that feed back into the core (age is one example due to Stat changes), but they don't have to be (Birthday does not, for example).  FactFacet and AgeFacet are examples of Fact Facts.
                        >
                        > We maintain "base" as the place for the abstract facet foundation for the other packages...
                        >
                        > So with that, I have the following packages
                        > pcgen.cdom.facet.action_global
                        > pcgen.cdom.facet.action_local
                        > pcgen.cdom.facet.analysis
                        > pcgen.cdom.facet.analysis_cached
                        > pcgen.cdom.facet.base
                        > pcgen.cdom.facet.display
                        > pcgen.cdom.facet.fact
                        > pcgen.cdom.facet.filter
                        > pcgen.cdom.facet.input
                        > pcgen.cdom.facet.model
                        > pcgen.cdom.facet.utility
                        >
                        > Open to input, I probably won't do this for a bit since I want to get a few more things into facets in preparation for this redo.
                        >
                        > Note also to Devon's point about "A Facet
                        shouldn't do more than one of these" - we have a few today that start to stretch these definitions, and it'll probably make sense to break them up into two facets.
                        >
                        > One thing I don't intend to do is break apart link facets.  Some of those can both listen and store and push events on changes, and I think that makes sense all in one place rather than arbitrarily forcing the listening/analysis to happen in one facet which directly writes to another.  MAYBE at some point some code consolidation can be done with that change, but that's pretty fine polishing to be worried about right now.
                        >
                        > TP.



                        ------------------------------------

                        Yahoo! Groups Links

                        <*> To visit your group on the web, go to:
                            http://groups.yahoo.com/group/pcgen_developers/

                        <*> Your email settings:
                            Individual Email | Traditional

                        <*> To change settings online go to:
                            http://groups.yahoo.com/group/pcgen_developers/join
                            (Yahoo! ID required)

                        <*> To change settings via email:
                            pcgen_developers-digest@yahoogroups.com
                            pcgen_developers-fullfeatured@yahoogroups.com

                        <*> To unsubscribe from this group, send an email to:
                            pcgen_developers-unsubscribe@yahoogroups.com

                        <*> Your use of Yahoo! Groups is subject to:
                            http://docs.yahoo.com/info/terms/



                      • javydreamer
                        What about actions.global and actions.local? Just my 2 cents.
                        Message 11 of 16 , Feb 10, 2012
                        • 0 Attachment
                          What about actions.global and actions.local?

                          Just my 2 cents.
                        • Tom Parker
                          haha.  Yea.  That would make sense.  How did I miss that... TP. ________________________________ From: javydreamer To:
                          Message 12 of 16 , Feb 10, 2012
                          • 0 Attachment

                            haha.  Yea.  That would make sense.  How did I miss that...

                            TP.


                            From: javydreamer <javier.ortiz.78@...>
                            To: pcgen_developers@yahoogroups.com
                            Sent: Friday, February 10, 2012 3:20 PM
                            Subject: [pcgen_developers] Re: Facet Organization

                            What about actions.global and actions.local?

                            Just my 2 cents.



                          • Martijn Verburg
                            FWIW - I think the facet split looks good - K
                            Message 13 of 16 , Feb 15, 2012
                            • 0 Attachment
                              FWIW - I think the facet split looks good - K

                              On 11 February 2012 11:33, Tom Parker <thpr@...> wrote:
                               


                              haha.  Yea.  That would make sense.  How did I miss that...

                              TP.


                              From: javydreamer <javier.ortiz.78@...>
                              To: pcgen_developers@yahoogroups.com
                              Sent: Friday, February 10, 2012 3:20 PM
                              Subject: [pcgen_developers] Re: Facet Organization

                              What about actions.global and actions.local?

                              Just my 2 cents.




                            • thpr
                              I have started these moves to clean up pcgen.cdom.facet TP.
                              Message 14 of 16 , Dec 9, 2012
                              • 0 Attachment
                                I have started these moves to clean up pcgen.cdom.facet

                                TP.

                                --- In pcgen_developers@yahoogroups.com, "thpr" <thpr@...> wrote:
                                >
                                > Looking through this further and now playing with some sample moves to see how well this works, I'm going to tweak and clarify this proposal a bit:
                                >
                                > (1) Input facets. These take input of something that has changed on a PC that will trigger a model change... such as adding a new piece of user equipment. This will trigger a set of events that may go right to the model or may go through the...
                                >
                                > (2) Link Facets. These take a certain type of object, and consolidate them down (or filter out those the PC is not qualified to have) and store the results into the...
                                >
                                > (3) Character "Model" Facets. Those that store the character model / character data (e.g. LanguageFacet) - these theoretically are replaceable by the CDOM graph at some point once we have them all. These are then read by...
                                >
                                > (4) Filter Facets: These facets reduce down the model facets into certain types of objects (e.g. just Natural Equipment) or consolidate them together into one big group (e.g. all objects granted to the PC). This can be used by
                                >
                                > (4) Action Facets: These facets look INTO the CDOMObjects and perform certain calculations that are relevant to PC behavior (e.g. triggering behavior from an ADD:). There are two groups of Action Facets: Global and Local. Often these facets will feed information (on things granted) into a filter or model facet. These facets, as well as the model and filter facets are listened to by display facets.
                                >
                                > (5) Analysis Facets: These facets look at CDOMObjects and perform calculations based on that information, e.g. calculating the number of hands. This are also often used by...
                                >
                                > (6) Display Facets: These facets simply take information from other facets and prepare it for output. This may be as simple as sorting a list of objects into alphabetical order.
                                >
                                > We also have:
                                >
                                > (7) Utility Facets: General overall things that don't fit elsewhere (Prerequisite testing, formula resolving)
                                >
                                > (8) Fact facets: These facets don't impact the model directly, but handle things that the user can modify (e.g. character age), and are NOT CDOMObject. (These objects cannot grant other objects)
                                >
                                > How do you distinguish an ___ facet?
                                >
                                > (1) Input facets are typically called directly from PlayerCharacter and are a "pass through" for a user action in the UI. However, they are NOT serving as a model facet (or they would be there), as they require some form of consolidation in order for all of the objects of that given type to get into the model. Example is UserEquipmentFacet.
                                > (2) Link Facets consolidate things from input facets or data from action facets and put them into the "pipeline" to reach the model. Generally these are "pass through", although they may test prerequisites. An example is ConditionallyGrantedAbilityFacet
                                > (3) Model facets are the "core" objects for each of the CDOMObjects. They are unlikely to have any local fields (any listening or listeners is set up by other facets). They must store CDOMObjects or some near derivative (e.g. SheildProfProvider). An example is RaceFacet.
                                > (4) Action Facets operate on the contents (key behavior is keying into the object to look at things set in the LST) of a granted object to potentially do additional granting. Example is AutoLanguageFacet (which reacts to AUTO:LANGUAGE token being present on a granted object)
                                > (5) Analysis Facets compare information from different facets to produce a piece of information. Rarely do they store information, and if they do it must only be a cache. Generally these are polled (display or other places pull information from these facets - they do not throw events). Example is HandsFacet.
                                > (6) Display Facets just produce output. I'm not actually sure we have any of these right now :)
                                > (7) Utility Facets serve an overall utility to other facets, such as resolving a formula, but do not serve a model, filtering, or other function. They should be stateless.
                                > (8) Fact facets are the other persistent piece of a PlayerCharacter other than the ModelFacets. These hold simple (non-CDOMObject) pieces of information, like the character age. These could be things that feed back into the core (age is one example due to Stat changes), but they don't have to be (Birthday does not, for example). FactFacet and AgeFacet are examples of Fact Facts.
                                >
                                > We maintain "base" as the place for the abstract facet foundation for the other packages...
                                >
                                > So with that, I have the following packages
                                > pcgen.cdom.facet.action_global
                                > pcgen.cdom.facet.action_local
                                > pcgen.cdom.facet.analysis
                                > pcgen.cdom.facet.analysis_cached
                                > pcgen.cdom.facet.base
                                > pcgen.cdom.facet.display
                                > pcgen.cdom.facet.fact
                                > pcgen.cdom.facet.filter
                                > pcgen.cdom.facet.input
                                > pcgen.cdom.facet.model
                                > pcgen.cdom.facet.utility
                                >
                                > Open to input, I probably won't do this for a bit since I want to get a few more things into facets in preparation for this redo.
                                >
                                > Note also to Devon's point about "A Facet shouldn't do more than one of these" - we have a few today that start to stretch these definitions, and it'll probably make sense to break them up into two facets.
                                >
                                > One thing I don't intend to do is break apart link facets. Some of those can both listen and store and push events on changes, and I think that makes sense all in one place rather than arbitrarily forcing the listening/analysis to happen in one facet which directly writes to another. MAYBE at some point some code consolidation can be done with that change, but that's pretty fine polishing to be worried about right now.
                                >
                                > TP.
                                >
                              • thpr
                                I have this on hold for a moment. I knew I would run into conflicts with tokens that fit into two buckets that would have to be separated. I thought I would
                                Message 15 of 16 , Dec 12, 2012
                                • 0 Attachment
                                  I have this on hold for a moment. I knew I would run into conflicts with tokens that fit into two buckets that would have to be separated.

                                  I thought I would work through that simply, but it turns out it takes a bit more effort than expected to clean up.

                                  It also raises some questions about the best structure to ensure the different categories can be clearly explained. So a bit of a delay here and perhaps an alternative proposal before this gets implemented.

                                  Sorry for the half-movement of stuff :/

                                  --- In pcgen_developers@yahoogroups.com, "thpr" <thpr@...> wrote:
                                  >
                                  > I have started these moves to clean up pcgen.cdom.facet
                                  >
                                  > TP.
                                • Martijn Verburg
                                  Take your time :-)
                                  Message 16 of 16 , Dec 12, 2012
                                  • 0 Attachment
                                    Take your time :-)

                                    On Thursday, 13 December 2012, thpr wrote:
                                     

                                    I have this on hold for a moment. I knew I would run into conflicts with tokens that fit into two buckets that would have to be separated.

                                    I thought I would work through that simply, but it turns out it takes a bit more effort than expected to clean up.

                                    It also raises some questions about the best structure to ensure the different categories can be clearly explained. So a bit of a delay here and perhaps an alternative proposal before this gets implemented.

                                    Sorry for the half-movement of stuff :/

                                    --- In pcgen_developers@yahoogroups.com, "thpr" <thpr@...> wrote:
                                    >
                                    > I have started these moves to clean up pcgen.cdom.facet
                                    >
                                    > TP.

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