[Smtk-developers] View (Continued)

Robert Maynard robert.maynard at kitware.com
Thu Apr 23 11:27:46 EDT 2015


Side note:

I don't see any reason why Components are Heap based. If they are
stack based the classes simplify nicely:

class Component
  {
  public:
    Component(const std::string &myName) : m_name(myName)
    {}

    const std::string &name() const
    {return this->m_name;}

    const std::string &contents() const
    {return this->m_contents;}
    void setContents(const std::string &c)
    {this->m_contents = c;}

    void setAttribute(const std::string &name, const std::string &value)
    {this->m_attributes[name] = value;}

    const std::string &attribute(const std::string &name)
    {return this->m_attributes[name];} // YES I know we need to see if
the name is there first

    const Component& addChild(const std::string &childName)
    {
      this->m_children.push_back( Component(childName) );
      return this->m_children.back();
    }

    std::size_t numberOfChildren() const
    { return this->m_children.size();}
    const Component& child(std::size_t i) const
    {return this->m_children[i];}

  protected:
    std::string m_name;
    std::string m_contents;
    std::map<std::string, std::string> m_attributes;
    std::vector<Component> m_children;
  };

  View(const std::string &myType, const std::string &myTitle) :
    m_type(myType),
    m_title(myTitle),
    m_details("Details")
  { }

  const std::string &title() const
  {return this->m_title;}

  const std::string &type() const
  {return this->m_type;}

  const Component& details() const
  {return this->m_details;}

protected:
  std::string m_title;
  std::string m_type;
  Component m_details;
};

As far as actually using the new views, I would have to spend some
time with john to look at how the old instanced viewer worked and if
this can replace it.

On Thu, Apr 23, 2015 at 11:17 AM, Robert Michael O'Bara
<bob.obara at kitware.com> wrote:
> Hi All,
>
> In the new design for Views I had failed to take into consideration the fact
> that Views might be defined within a C++ piece of code and not just through
> XML.  In order to avoid developers having to create XML document strings in
> their code to create a View I modified the proposed View class to no longer
> just contain a XML string.  Instead it now looks like the following
> structure which can capture the information in the XML description without
> forcing XML to spread in the code base.  I also included examples as to how
> Views could be constructed in C++.
>
> Let me know what you think.
>
> Bob
>
> #include <map>
> #include <vector>
> #include <string>
>
> class View
> {
> public:
>   class Component
>   {
>   public:
>     Component(const std::string &myName) : m_name(myName)
>     {}
>
>     ~Component()
>     {
>       for(std::size_t i = 0; i < this->m_children.size(); ++i)
>         {
>         delete this->m_children[i];
>         }
>     }
>
>     const std::string &name() const
>     {return this->m_name;}
>
>     const std::string &contents() const
>     {return this->m_contents;}
>     void setContents(const std::string &c)
>     {this->m_contents = c;}
>
>     void setAttribute(const std::string &name, const std::string &value)
>     {this->m_attributes[name] = value;}
>
>     const std::string &attribute(const std::string &name)
>     {return this->m_attributes[name];} // YES I know we need to see if the
> name is there first
>
>     Component *addChild(const std::string &childName)
>     {
>       Component *c = new Component(childName);
>       this->m_children.push_back(c);
>       return c;
>     }
>     std::size_t numberOfChildren() const
>     { return this->m_children.size();}
>     Component *child(std::size_t i) const
>     {return this->m_children[i];}
>
>   protected:
>     std::string m_name;
>     std::string m_contents;
>     std::map<std::string, std::string> m_attributes;
>     std::vector<Component *> m_children;
>   };
>
>   View(const std::string &myType, const std::string &myTitle) :
> m_type(myType), m_title(myTitle)
>   { this->m_details = new Component("Details");}
>
>   ~View()
>   {delete this->m_details;}
>
>   const std::string &title() const
>   {return this->m_title;}
>
>   const std::string &type() const
>   {return this->m_type;}
>
>   Component *details() const
>   {return this->m_details;}
>
> protected:
>   std::string m_title;
>   std::string m_type;
>   Component *m_details;
> };
>
> int main()
> {
>   View::Component *c;
>   View sview("SimpleExpression", "Functions");
>   sview.details()->setContents("PolyLinearFunction");
>
>   View aview("Attribute", "BoundaryConditions");
>   aview.details()->setAttribute("ModelEntityFilter", "f");
>   aview.details()->addChild("SpecifiedHead");
>   aview.details()->addChild("SpecifiedFlux");
>   aview.details()->addChild("FlowInjectionWell");
>   aview.details()->addChild("METData");
>   aview.details()->addChild("GroundSurfaceHeatFlux");
>   aview.details()->addChild("UseMETData");
>   aview.details()->addChild("RayCaster");
>   aview.details()->addChild("BottomBoundaryTemp");
>
>   View iview("Instanced", "Time");
>   c = iview.details()->addChild("Instance");
>   c->setAttribute("Type", "Time");
>   c->setContents("Time");
>
>   View rview("Root", "SimBuilder");
>   c = rview.details()->addChild("DefaultColor");
>   c->setContents("1., 1., 0.5, 1.");
>   c = rview.details()->addChild("InvalidColor");
>   c->setContents("1., 0.5, 0.5, 1.");
>   c = rview.details()->addChild("Views");
>   c->addChild("Functions");
>   c->addChild("BoundaryConditions");
>   c->addChild("Time");
> }
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931
>
>
>
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>


More information about the Smtk-developers mailing list