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

Re: Facet Organization

Expand Messages
  • thpr
    I have started these moves to clean up pcgen.cdom.facet TP.
    Message 1 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 2 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 3 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.