We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 9102 ☆ A M B ☆
    • 318 Posts
    I'm developing an extra that actually consists of multiple components, some of which might be useful by themselves. However, there are relationships among the components, and I want to represent those relationships in my schema, so that I can easily get the objects that are related to each other.

    Can you design an extra so that different pieces of it can be used independently, and still model their relationships in your schema?

    Or should I develop the whole thing as a single model, and then later split off the components as separate Extras? It seems like that would be harder to maintain, as I would have to deploy upgrades separately to the integrated extra and to each of the independent components.
      • 33976 ☆ A M B ☆
      • 571 Posts
      Hi,

      I had the problem too. I came up with 2 solutions :

      1 - a component can extend another component's tables. The problems come when you need to extend an object more than once (you also might have to "redo" your processors to use the extended object).

      2 - as you said, think your components set as a whole component, creating all your relationships assuming all your components are installed. For me this is the more convenient way for now (and the way i did).

      Hoping the core team will shred some light on "best practice"/recommendation on how to handle that situation.

      Till then, hope that will help a little bit
        • 9102 ☆ A M B ☆
        • 318 Posts
        Thanks for your insight romain. For now I'm keeping the whole thing together as a single package, and maybe when I'm more experienced I'll think about how to break it up while still maintaining the relationships.
          • 22303 MODX Staff
          • 10,725 Posts
          Creating and maintaining a library of loosely-coupled components that work alone and in intended configurations with each other can be more difficult than just creating a tightly-coupled component, for sure. But if the reusability of specific individual pieces are worth the extra effort, I certainly suggest creating separate components, though you could still package them together, to ease upgrade concerns if that made sense.

          As for CMPs that may be part of these Extras, this is where isolation of the pieces would be important, so they could be used independently. Then again, if they are installed together as a single package of related components, it may not matter if they are all managed through a single CMP.
            • 9102 ☆ A M B ☆
            • 318 Posts
            It would be easy enough to do separate CMPs. The part I'm not certain about how to handle is the relationships between tables in the schema.

            I have two pieces that could be treated entirely separately, except that if they are installed together there should be a one-to-many relationship between a table in one and a table in the other. So that basically means maintaining three schemas - one for the components installed together, and one for each of them separately.

            In the long run it's probably worth it to do that, but for now I'm just going to write it as a single model, keeping in mind that I want to separate them out eventually.

            Thanks for the answer to this, opengeek, your wisdom is always welcome.