Hello Vivek, this is probably too far but it’s always good to have further plans. Here are two possible extension avenues which would be useful for the blockly world, I believe:
- create a workflow that allows custom-blocks to be included in the toolbox using a similar experience as the xwiki extension manager (there was a GSoC on bringing more repositories for this manager last year) - employ the real-time editing extension or parts of it (e.g. chainpad-listmap) so that a blockly page can be edited in synchronicity between teachers and students (where used can be _edited_ or even _run_). CodePen seems to allow such features. thanks paul On 4 May 2018, at 22:28, Vivek Iyer wrote: > 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 <vinc...@massol.net> wrote: > >> >> >>> On 4 May 2018, at 10:52, Vincent Massol <vinc...@massol.net> wrote: >>> >>> Hi Vivek, >>> >>>> On 4 May 2018, at 10:15, Vivek Iyer <vivekbalasunda...@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 >> >>
signature.asc
Description: OpenPGP digital signature
