Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Replying to issues #30

Open
ElDragonRojo opened this issue Aug 1, 2013 · 0 comments
Open

Replying to issues #30

ElDragonRojo opened this issue Aug 1, 2013 · 0 comments
Assignees
@ElDragonRojo
Labels
details feature implementation
Milestone
Talk on iPhone

Comments

@ElDragonRojo
Copy link
Contributor

Once we can create new topics in the form of issues, refs #5, we want to reply to those issues by creating comments.

In this limited case, we can see comments and issues as forming a kind of meta-class called LETalk, with issues being a kind of container subclass of comments.

Realistically, comments can be attached to lots of classes we are simply not considering yet.

Therefore, we will have to make an architectural decision whether to have a set of keys the non-nil version of which tells what’s happening (as with UIViewController and friends) or to factor out the common “parent” object to which all comments can belong.
@ghost ghost assigned ElDragonRojo Aug 1, 2013
ElDragonRojo added a commit that referenced this issue Aug 1, 2013
@ElDragonRojo
Add API to GHComment to access its parent issue.
ba6e17f 
This implementation and relationship is intentionally naïve.

Refs #30
ElDragonRojo added a commit that referenced this issue Aug 1, 2013
@ElDragonRojo
In GitHub, replies are comments, and comments are, at least in this u…
8c531ed 
…se case—attached to issues.

In the UI, issues and comments both contain some common conceptual sub-object called a talk, which has a body. (Seeing the problem as Composition versus Inheritance, Refs #31)

In the code, issues and comments are both kinds of talks, their common API unified behind the LETalk protocol.

In any case, the user may be replying to the top-level issue or one of its comments, but they both result in the same thing: a new comment being added to the issue.

Therefore, we have to disambiguate between whether the current talk is the issue, or the current talk is contained by the issue. For this we can introspect the actual class of the talk, and use the issue back pointer if necessary.

## Next steps

1. Create a comment and attach it to the issue.
2. Ensure this is done in a way that is compatible with the coming sync architecture.
3. Actually sync these changes.

Refs #30
ElDragonRojo added a commit that referenced this issue Aug 1, 2013
@ElDragonRojo
# Reply from Preview
6c41e61 
## Experience

1. If you are looking at a talk that you have not changed, and you are in preview mode, the save button is a reply button.
2. Tapping the reply button creates a new comment and opens that comment in the editor.
3. Editing the comment works as expected, and is added to the conversation aka talk list.

## LEWorkViewController

* Finished the reply method, which now adds the new comment to the current issue or comment’s issue, refs #30

## GHIssue

* Add a comment adding method that conveniently adds the new comment to the issue.
* Add named constants for the comments key and property.

## GHComment

* Add a comment factory similar to that employed by GHIssue
  * The difference being there is only one new comment.
  * This will let us explore how to deal with unsynced comments and issues, refs #31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ElDragonRojo ElDragonRojo

Labels
details feature implementation
Projects
None yet
Milestone
Talk on iPhone
Development

No branches or pull requests
1 participant
@ElDragonRojo