Hello All
I have several contexts that allow an item in a nested set to be moved to any other point within the nested set. Each element in the tree has a parent, and children of a parent are ordered.
Currently I have 3 contexts that allow items to be moved to any other point in the tree :
class MoveAfterItem < Context
def new(source_item, target_item)
def execute
class MoveBeforeItem < Context
def new(source_item, target_item)
def execute
class MoveWithinItem < Context
def new(source_item, target_item)
def execute
Although this works fine I feel as though I haven't structured my Contexts using the use cases of the application.
I think the use case is "Be able to move items around the tree".
Based on this I think I should create a new single context that replaces the 3 other ones. This new context has 3 entry points :
class MoveItemAroundTree < Context
def new(source_item, target_item)
def move_after_item
def move_before_item
def move_within_item
Being able to move items around the tree is a major part of the functionality of this app. The application is a simple note taking application, where notes are arranged in a tree structure, any number of levels deep.
What are your thoughts on the new Context I have created? Any help is appreciated.
Regards
Chris
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/jRF8nw9s928J.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.
Hi chris,
Did you say you have working code for this or just at design stage? As im curious to see the code you have?
From what i read from your posts, your talking about represtational state and interactions, rather than system operations.
I think you should consider the Context for this inside the users mind. This can not be coded into your software as an object.
The users is performing the steps and not the software.
Mike brown.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/5TrwtYSyio8J.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsubscribe@googlegroups.com.
Hi,
What you implemented looks like a command pattern. That's perfectly fine for the operations you mean to perform. You're performing direct manupilation of the data. There is no real interaction taking place between the subjected nodes.
DCI is not a silver bullet. For 1:1 manupilation of data classes you're better of with a straight forward command pattern (there is no use case specific behaviour involved, no roles).
Just my 2ct.
Regards,
Arjan
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/8J9ebP_lz8cJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/8J9ebP_lz8cJ.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/8J9ebP_lz8cJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/-UlQHf7NEzQJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/8J9ebP_lz8cJ.
To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/-UlQHf7NEzQJ.
> How can a decision to move something not include a description of the position relative to another object that it should be moved to?
Pete: "James would you please move your chair over there" (Pete points
to the exact location between Laura and Kent)" it's not before Kent or
after Laura. It's relative to there position and it's "right there".
Human languages are a lot richer than programming language even though
in this case also vague (pointing is non-verbal). The users mental
model is not based on what can or what needs to be expressed when
coding a solution. Drag and drop feels natural because you tell the
computer to move stuff to "right there" you point with a mouse instead
of a finger. Describing the exact position is only needed when
straying from this real world solution.
Of course Pete could also say "James please move your chair" "Laura I
want James chair before yours" which is equivalent to first selecting
the object to be moved and then selecting the object it should be
placed before. Does that sound natural?
> I initially used drag and drop but found it clumsy for my application. Even when I used Drag and Drop, "Move Before", "Move After" and "Move Within" are still the operations being performed.
My point is not that I think drag n drop is the perfect solution. As
I've understood your system the user does the following:
Selects an element to move
Click move before/after/within on a separate element
I don't think a regular user would think that way at least not without
having used the application for at while. That's not saying the
implementation is not working simply that I believe the operation the
user wish to perform is "move this element right there" the
interaction represents the operation the user wishes to perform.
Sometimes in software we invent entirely new ways of doing things that
our users have been doing for years but more commonly we support users
in doing what they have been doing for years. We create system that
fits into existing work flows. It's a lot easier to get users to
accept new systems if they simply make their every day life simpler.
At times there might be a benefit in challenging the users model of
how they should perform their work. The point I was trying to make is
that I think moving an element from A to B is in the first category.
Support the operation the user wish to perform and if at all possible
don't ask the users to concern them self with how it's implemented