Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Refactoring/rewriting this complicated location checking mechanism out of the viewer into a dedicated class makes sense, so you can improve your solution without affecting the rest of your program. Lets call this <code>NodeToWidgetMap</code>.</p> <p><strong>Architecture</strong><br/> Seems your heading towards a <a href="http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html" rel="nofollow"><strong>Model-View-Controller</strong></a> architecture which is a good thing IMO. Your tree structure and its nodes are the models, where as the viewer and the "widgets" are views, and the logic selecting widgets depending on the node would be part of a controller. </p> <p>The main question remains when and how you choose the widget w<sub>N</sub> for a given node N and how to store this choice. </p> <p><strong>NodeToWidgetMap: When to choose</strong><br/> If you can assume that w<sub>N</sub> does not change during its lifetime even though nodes are moved, you could choose it right when creating the node . Otherwise you'll need to know the location (or path through the XML) and, in consequence, find the parent of a node when requesting it.</p> <p><strong>Finding Parent Nodes</strong><br/> My solution would be to store <em>pointers to</em> instead of the node instances themselves, perhaps using <code>boost::shared_ptr</code>. This has drawbacks, for example copying nodes forces you to implement your own copy-constructors that uses recursion to create a deep-copy of your sub-tree. (Moving however will not affect the child nodes.)</p> <p>Alternatives exist, such as keeping child nodes uptodate whenever touching the parent node respective the grandfathers vector. Or you can define a <code>Node::findParentOf(node)</code> function knowing that certain nodes can only (or frequently) be found as child of certain nodes. This is brute but will work reasonably well for small trees, just does not scale very well.</p> <p><strong>NodeToWidgetMap: How to choose</strong><br/> Try writing down the rules how to choose w<sub>N</sub> on piece of paper, perhaps just partially. Then try to translate these rules into C++. This might slightly longer in terms of code but will be easier to understand and maintain. </p> <p>Your current approach is to use regular expressions for matching the XML path (stack).</p> <p>My idea would be to create a lookup graph whose edges are labelled by the XML element names and whose nodes indicate which widget shall be used. This way your XML path (stack) describes a route through the graph. Then the question becomes whether to explicitly model a graph or whether a group of function calls could be used to mirror this graph.</p> <p><strong>NodeToWidgetMap: Where to store choice</strong><br/> Associating a unique, numeric id to each node, record the widget choice using a map from node id to widget inside the NodeToWidgetMap.</p> <p><strong>Rewriting vs Refactoring</strong><br/> If you rewrite you might get good leverage tieing to an existing framework such as Qt in order to focus on your program instead of rewriting the wheels. It can be easier to port a well-written program from on framework to another than to abstract around the pecularities of each platform. Qt is a nice framework for gaining experience and good understanding of the MVC-architectures.</p> <p>A complete rewrite gives you a chance to rethink everything but implies the risk that you start from scratch and will be without a new version for a good amount of time. And who knows whether you will have enough time to finish? If you choose to refactor the existing structures you will improve it step by step, having a useable version after each step. But there is small risk to remain trapped in old ways of thinking, where as rewriting nearly forces you to rethink everything. So both approaches have their merits, if you enjoy programming I would rewrite. More programming, more joy.</p>
    singulars
    1. This table or related slice is empty.
    1. POProgramming paradigm; wondering if rewriting/refactoring is necessary
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USLothar_K
    1. USLothar_K
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POProgramming paradigm; wondering if rewriting/refactoring is necessary
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COMeh I'm definitelly going to to rewrite I guess.. This project really shows a lot of changes. Before it I was just "proficient with c++/stl", however I never did anything large. Now I learned qt, and many other things I needed (C++11). I can really see difference in code style to the point I'm ashamed of it.
      singulars
      1. PO
      1. USpaul23
    2. COmeh, sorry for numerous edits, seems you run into "The Law of Conservation of Difficulty"
      singulars
      1. PO
      1. USLothar_K
    3. COHmm well I could actually go with the "nodekind" approach; nodes will keep their type (and are just added to other trees). However this
      singulars
      1. PO
      1. USpaul23
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload