Hi all, I am so much happy to tell you all that my project proposal has been accepted for GSOC 2015 :) . From the beginning of the work up to now I had so much help from the community members to go over the first hurdle. Specially Robert and Alex gave me a great support for the proposal by proof reading and providing valuable advices. Thank you all again. :)
Cheers On Fri, Apr 24, 2015 at 12:45 AM, Nadeeshaan Gunasinghe < nadeeshaangunasin...@gmail.com> wrote: > Hi all, > Is there any way of parsing multipart data in Fauxton? An example would be > so much helpful . > :) > > Regards > > On Tue, Apr 14, 2015 at 9:09 PM, Nadeeshaan Gunasinghe < > nadeeshaangunasin...@gmail.com> wrote: > >> Hi Robert, >> As you suggested here is the link for my react component testing >> development branch. At the moment I am completing the react lessons and one >> left to go. >> :) >> >> https://github.com/nadeeshaan/couchdb-fauxton/tree/InitialTestingBranch >> >> Cheers. >> >> On Sat, Apr 4, 2015 at 5:08 PM, Nadeeshaan Gunasinghe < >> nadeeshaangunasin...@gmail.com> wrote: >> >>> Hi Robert, >>> I followed the resources you shared previously and I could successfully >>> create a react component to display some content on the view. >>> >>> For the reference of other newbies like me who try to create react >>> components I would like to suggest taking a look at on >>> app/addons/cors >>> app/addons/config >>> >>> as well as >>> https://github.com/nadeeshaan/couchdb-fauxton/blob/master/writing_addons.md >>> >>> Going through those we can successfully create a react component. :) >>> >>> Cheers >>> >>> On Wed, Mar 25, 2015 at 2:37 AM, Nadeeshaan Gunasinghe < >>> nadeeshaangunasin...@gmail.com> wrote: >>> >>>> Hi Robert, >>>> As you suggested yesterday I started generating the UIs in the fauxton >>>> Code base. I followed the sample addon writing tutorial in github and went >>>> through the already written addons. As a first step I could get an idea >>>> about how the data is flowing through fauxton and how content is managed. >>>> So as my next step I am going to try writing a bit more complex UI adding >>>> bits of components there. >>>> Cheers >>>> >>>> On Mon, Mar 23, 2015 at 6:13 PM, Alexander Shorin <kxe...@gmail.com> >>>> wrote: >>>> >>>>> Very good! Such layout indeed have better potential to handle upcoming >>>>> feature requests. I wouldn't concentrate here on the details (like >>>>> action menu - it's uncommon for Fauxton interface to have a dropdown >>>>> list of actions since buttons are preferred instead) - the idea and >>>>> the base layout are more important at the start. Robert, what do you >>>>> think? >>>>> -- >>>>> ,,,^..^,,, >>>>> >>>>> >>>>> On Mon, Mar 23, 2015 at 3:15 PM, Nadeeshaan Gunasinghe >>>>> <nadeeshaangunasin...@gmail.com> wrote: >>>>> > Hi Robert, >>>>> > According to the suggestions of Alex I re designed the Interface. It >>>>> will >>>>> > be great if you can give some feedback regarding the current UI. >>>>> > I will point to each suggestion as follows, >>>>> > >>>>> > >>>>> > *1. Tree could be wide. Very wide and tall. Proposed interface has a >>>>> quite >>>>> > small limit for amount of conflicts which could be showed without >>>>> having >>>>> > horizontal scrolling. How this is suppose to be handled? * >>>>> > Tree is being shown inside a scrollable (Horizontal and vertical >>>>> only if >>>>> > the tree does not fit in side the pane) pane in which we can click >>>>> on the >>>>> > nodes and traverse the tree allowing much wider as well as taller >>>>> trees >>>>> > >>>>> > *2. Tree is used to only to look it at and browse document for each >>>>> > selected revision, but also to apply some kind of operation: "revert >>>>> to", >>>>> > delete, merge, etc. Proposed interface doesn't assumes to have any >>>>> bar for >>>>> > such operations.* >>>>> > Above the tree's display pane there is a drop down select in order to >>>>> > select the desired operation to be done. As an example merge, revert >>>>> to, >>>>> > etc. >>>>> > Ex: If you select the merge option then you are allowed to select >>>>> two tree >>>>> > nodes. If you select delete option or explore (Default Option) then >>>>> you are >>>>> > allowed to select one node. >>>>> > When you select such option, as an example merge, two nodes' document >>>>> > content will be shown in the two document view panes. Relevant >>>>> revision id >>>>> > is shown above the corresponding pane. >>>>> > >>>>> > *3. Document content for some revisions may not be available. What >>>>> will be >>>>> > showed on the right pane in this case?* >>>>> > If the content of a revision is not available then the pane will be >>>>> left >>>>> > blank (No more right side pane in the available pane) >>>>> > >>>>> > *4. During the conflict resolution, or merge, you'll need to see both >>>>> > conflict documents and the result of their merge. How proposed >>>>> interface >>>>> > could help with that?* >>>>> > At the top right corner above the display panes there is an icon of >>>>> eye. >>>>> > Clicking on it, a modal opens and shows the result of the operation >>>>> > >>>>> > *5. Will navigation to revision tree page be available from document >>>>> view >>>>> > page?* >>>>> > Yes. This issue had addressed in the previous version. In which we >>>>> are >>>>> > adding a link to each document (A tree icon left to the pencil icon) >>>>> which >>>>> > redirect to the revision tree page. >>>>> > >>>>> > *Features for operations.* >>>>> > Options: >>>>> > Explore >>>>> > Revert to >>>>> > Merge >>>>> > Delete >>>>> > >>>>> > In the operation selection drop down there is a default option >>>>> *"Explore" *when >>>>> > this is selected "eye icon", "Apply Button" will be disabled. Also >>>>> only one >>>>> > pane will be shown for loading the document content >>>>> > Delete works as same and only the "Apply Button" won't be disabled >>>>> > >>>>> > At the moment I focused on the above options only depending on the >>>>> options >>>>> > we can to alterations for the UI based on the current View. During >>>>> the >>>>> > implementation there may be slight changes of the designed, but the >>>>> basic >>>>> > structure will remain same. >>>>> > >>>>> > Links to the UIs, >>>>> > >>>>> > Documents view: >>>>> > >>>>> https://www.dropbox.com/s/oezvfztq9abqtv5/alldocs_added_tree_icon.png?dl=0 >>>>> > Revision Tree View: >>>>> > >>>>> https://moqups.com/nadeeshaangunasin...@gmail.com/57ApYGyp/p:a2a67f660 >>>>> > >>>>> > Cheers, >>>>> > >>>>> > On Sun, Mar 22, 2015 at 10:17 AM, Nadeeshaan Gunasinghe < >>>>> > nadeeshaangunasin...@gmail.com> wrote: >>>>> > >>>>> >> Hi Alex, >>>>> >> Thank you very much for pointing out the missing things and the >>>>> critical >>>>> >> functionality suggestions. >>>>> >> I designed these uis in order to show how we are going to/where we >>>>> are >>>>> >> going to show the revision tree. >>>>> >> As you suggested I am redesigning the ui in order to support the >>>>> critical >>>>> >> functionalities. I will send the re designed mockups asap for your >>>>> >> inspection. >>>>> >> BR >>>>> >> ------------------------------ >>>>> >> From: Alexander Shorin <kxe...@gmail.com> >>>>> >> Sent: 3/21/2015 11:55 PM >>>>> >> To: dev@couchdb.apache.org >>>>> >> Subject: Re: GSOC 2015 [Visualize document revision tree and >>>>> navigate >>>>> >> betweenthese revisions] >>>>> >> >>>>> >> On Sat, Mar 21, 2015 at 8:26 PM, Nadeeshaan Gunasinghe >>>>> >> <nadeeshaangunasin...@gmail.com> wrote: >>>>> >> > >>>>> >> >>>>> https://www.dropbox.com/s/oezvfztq9abqtv5/alldocs_added_tree_icon.png?dl=0 >>>>> >> > https://www.dropbox.com/s/36mmwy4r46nn1l7/revTreeMockup.png?dl=0 >>>>> >> >>>>> >> Good start. Now let's try to think how this feature could be used in >>>>> >> real. This will give us the following questions: >>>>> >> 1. Tree could be wide. Very wide and tall. Proposed interface has a >>>>> >> quite small limit for amount of conflicts which could be showed >>>>> >> without having horizontal scrolling. How this is suppose to be >>>>> >> handled? >>>>> >> 2. Tree is used to only to look it at and browse document for each >>>>> >> selected revision, but also to apply some kind of operation: "revert >>>>> >> to", delete, merge, etc. Proposed interface doesn't assumes to have >>>>> >> any bar for such operations. >>>>> >> 3. Document content for some revisions may not be available. What >>>>> will >>>>> >> be showed on the right pane in this case? >>>>> >> 4. During the conflict resolution, or merge, you'll need to see both >>>>> >> conflict documents and the result of their merge. How proposed >>>>> >> interface could help with that? >>>>> >> 5. Will navigation to revision tree page be available from document >>>>> view >>>>> >> page? >>>>> >> >>>>> >> -- >>>>> >> ,,,^..^,,, >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Nadeeshaan Gunasinghe >>>>> > Department of Computer Science and Engineering >>>>> > University of Moratuwa >>>>> > Sri Lanka >>>>> >>>> >>>> >>>> >>>> -- >>>> Nadeeshaan Gunasinghe >>>> Department of Computer Science and Engineering >>>> University of Moratuwa >>>> Sri Lanka >>>> >>> >>> >>> >>> -- >>> Nadeeshaan Gunasinghe >>> Department of Computer Science and Engineering >>> University of Moratuwa >>> Sri Lanka >>> >> >> >> >> -- >> Nadeeshaan Gunasinghe >> Department of Computer Science and Engineering >> University of Moratuwa >> Sri Lanka >> > > > > -- > Nadeeshaan Gunasinghe > Department of Computer Science and Engineering > University of Moratuwa > Sri Lanka > -- Nadeeshaan Gunasinghe Department of Computer Science and Engineering University of Moratuwa Sri Lanka
