On 4 May 2018, at 10:52, Vincent Massol <vincent(a)massol.net> wrote: Hi Vivek, Welcome aboard :) I’ve had a quick look and it would be nice if you could reformulate the use cases in term of features that the extensions needs to support. For example instead of saying: - The user enters his credentials. - If authenticated, he is redirected to the dashboard. - If the user is unable to authentinicate, the user is shown an error message saying invalid credentials You should simply say: * Allow users to enter Google credentials in the Admin UI. Question: is this needed? Why do we need to enter credentials? AFAICS there’s no need to provide any credentials except if we wanted the optional cloud storage (which is not something we want IMO since the storage is going to be in wiki pages). Also you say: - The user navigates to the page he wishes to edit. - He selects the edit option and if he's an advanced user, he sees the Blockly editor and selects it You should simply say: * Add a page editor to the list of available editors (Wiki, WYSIWYG, etc) so that users can edit a page using the Blockly editor You’re also missing this: * Ability to define the Blockly editor as the default editor in the Admin and in the use’s profile Also you say: - The Blockly editor contains various blocks for performing common XWiki scripting actions - The user selects the appropriate blocks which show up as code on the side div - Once the user is done with the scripting, he clicks on the save and continue button - He is then redirected and is able to view his changes. This is not needed as it’s pretty obvious ;) This is just describing the usage of the extension, not the requirements for the integration. You can put it in a usage section if you want though. Also you say: - If the user is not an advanced user, he won't see the Blockly editor option and would need to go to Settings and enable Advanced User in Preferences. I’m not sure we want this since the goal is to try to make it as simple as possible for any type of users to write some simple scripts in xwiki. I wouldn’t put such restriction and would simply make it available to both simple and advanced users. Then you’re missing lots of use cases…. I’ll write some but you should be the one finishing the list: - Ability to generate any scripting language output when saving the page, and starting with Velocity. - Ability to convert scripts writing in any scripting language into a visual Blockly view, starting with Velocity. This needs to be explored and if this is not possible then it means saving the Blockly data into a XObject of the pages and offering a custom Edit Sheet to use that when editing the page with the Blockly Editor.

- Provide several Blocks by default that allow to do things in XWiki. Review common actions that need to be done in scripting and offer blocks for them. For example: Ability to write XWQL queries to return a list of pages and ability to execute actions on them: replace content, copy, rename, delete. Send email. Etc. You can see the velocity scripting guide to get ideas of commons things that need to be supported: https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Scripting/APIGu… - Add ability for developers to create/edit new Blockly Blocks inside wiki pages. All the provided blocks by default should be using this strategy so they can be modified. I’ll let you port these use cases into the design doc! :) I’m happy that we’re getting started. Thanks! -Vincent > > That's all from my side. I'm eager for your feedback and happy to receive > any suggestions as to where I could improve my current schedule. > > Thanks and regards, > Vivek Iyer

Sir, I've made the changes in the design page as requested! I think you covered most of the use cases, I tried thinking of more but I couldn't come up with any relevant ones. Like the basic use cases are the conversion of blocks to code and vice versa, and CRUD operations on blocks and those have been covered. I think I should focus on implementing these use cases and getting the basics right, and then maybe if time permits, I can add support for other programming languages too! Regards, Vivek Iyer On Fri, May 4, 2018 at 2:23 PM, Vincent Massol <vincent(a)massol.net> wrote: > > >> On 4 May 2018, at 10:52, Vincent Massol <vincent(a)massol.net> wrote: >> >> Hi Vivek, >> >>> On 4 May 2018, at 10:15, Vivek Iyer <vivekbalasundaram(a)gmail.com> > wrote: >>> >>> Hello all! >>> My name is Vivek Iyer (github and Riot handle: Remorax) and I'm so > grateful >>> for being selected as part of GSoC and I'm honestly looking forward to >>> contributing here! >> >> Welcome aboard :) >> >>> >>> My project for the summer is the Google Blockly Editor and to integrate > it >>> with the current wiki and WYSIWYG editors. I plan to do this in four >>> stages: >>> - Firstly develop a small extension as test, so that I can build up on > it. >>> - The second stage would be actually integrating a basic Blockly editor > in >>> XWiki. >>> - The third stage would be adding custom blocks which generate the code > for >>> functions which are most commonly used >>> - The fourth and the last stage would be making these blocks output >>> Velocity (or alternatively JS) code which would substitute the contents > of >>> the div which would normally contain the manually written code. >>> >>> Ideally, I plan on finishing stages 1 and 2 before the first evaluation, >>> stage 3 before the second evaluation and stage 4 before the final >>> evaluation. >>> >>> As mentioned in my proposal, I'll be on vacation from 10th to 20th May > and >>> won't have internet access so I'll be unable to contribute during that >>> period, but I'll surely make up for the lost time later on and get the > work >>> done on schedule! >>> >>> I've also kept buffer slots in between in case I run behind schedule. >>> >>> I have also made a design on design.xwiki.org here: >>> http://design.xwiki.org/xwiki/bin/view/Google-Blockly-Editor/ >>> Do check it out and let me know your opinions! >> >> I’ve had a quick look and it would be nice if you could reformulate the > use cases in term of features that the extensions needs to support. >> >> For example instead of saying: >> >> - The user enters his credentials. >> - If authenticated, he is redirected to the dashboard. >> - If the user is unable to authentinicate, the user is shown an error > message saying invalid credentials >> >> You should simply say: >> >> * Allow users to enter Google credentials in the Admin UI. >> >> Question: is this needed? Why do we need to enter credentials? AFAICS > there’s no need to provide any credentials except if we wanted the optional > cloud storage (which is not something we want IMO since the storage is > going to be in wiki pages). >> >> Also you say: >> >> - The user navigates to the page he wishes to edit. >> - He selects the edit option and if he's an advanced user, he sees the > Blockly editor and selects it >> >> You should simply say: >> >> * Add a page editor to the list of available editors (Wiki, WYSIWYG, > etc) so that users can edit a page using the Blockly editor >> >> You’re also missing this: >> >> * Ability to define the Blockly editor as the default editor in the > Admin and in the use’s profile >> >> Also you say: >> >> - The Blockly editor contains various blocks for performing common XWiki > scripting actions >> - The user selects the appropriate blocks which show up as code on the > side div >> - Once the user is done with the scripting, he clicks on the save and > continue button >> - He is then redirected and is able to view his changes. >> >> This is not needed as it’s pretty obvious ;) This is just describing the > usage of the extension, not the requirements for the integration. You can > put it in a usage section if you want though. >> >> Also you say: >> >> - If the user is not an advanced user, he won't see the Blockly editor > option and would need to go to Settings and enable Advanced User in > Preferences. >> >> I’m not sure we want this since the goal is to try to make it as simple > as possible for any type of users to write some simple scripts in xwiki. I > wouldn’t put such restriction and would simply make it available to both > simple and advanced users. >> >> Then you’re missing lots of use cases…. I’ll write some but you should > be the one finishing the list: >> >> - Ability to generate any scripting language output when saving the > page, and starting with Velocity. >> - Ability to convert scripts writing in any scripting language into a > visual Blockly view, starting with Velocity. This needs to be explored and > if this is not possible then it means saving the Blockly data into a > XObject of the pages and offering a custom Edit Sheet to use that when > editing the page with the Blockly Editor. > > s/scripts writing/script written > > -Vincent > >> - Provide several Blocks by default that allow to do things in XWiki. > Review common actions that need to be done in scripting and offer blocks > for them. For example: Ability to write XWQL queries to return a list of > pages and ability to execute actions on them: replace content, copy, > rename, delete. Send email. Etc. You can see the velocity scripting guide > to get ideas of commons things that need to be supported: > https://www.xwiki.org/xwiki/bin/view/Documentation/ > DevGuide/Scripting/APIGuide/ >> - Add ability for developers to create/edit new Blockly Blocks inside > wiki pages. All the provided blocks by default should be using this > strategy so they can be modified. >> >> I’ll let you port these use cases into the design doc! :) >> >> I’m happy that we’re getting started. >> >> Thanks! >> -Vincent >> >> >> >> >> >> >> >> >>> >>> That's all from my side. I'm eager for your feedback and happy to > receive >>> any suggestions as to where I could improve my current schedule. >>> >>> Thanks and regards, >>> Vivek Iyer > >