GSOC 2012

92 views
Skip to first unread message

Vivek

unread,
Mar 23, 2012, 12:12:07 PM3/23/12
to silverst...@googlegroups.com
Hi 
I am Vivek and i am studying engineering in IIT Delhi and i really appreciate the whole cms system 
system put together by silverstripe. Its simple and resiient. But i found the project
regarding Improvement of silverstripe Modules and widgets page prety interesting and important. The modules and widgets page
can indeed be made more compact. Search results can be more optimised so that people see the relevant results. Another good 
addition could be the display of keywords that are most frequently searched. this would further optimise the search and make it 
easier.

A filter by categories which includes something like latest, most downloaded and most relevant would be a great addition and it
is used in many cms like wordpress which makes the search a better experience.

Users can also rate and comment a module and bring out compatibility related issues which 
can help other users a great deal. I have sm basic idea of how the page should look like but i got
my college mid terms right now. So i am not able to put in that much time into research right now.
But i can assure you i will get down to designing the basic layout and functionality as soon as i am done
with my exams.

I have worked with wordpress before and have a good knowledge about front end javascript,html and css
am also prety comfortable with php and mysql. 
I would be really glad if the mentors could guide me and tell me where i go wrong. I am always open to learning and 
improving.


Thanks 

xeraa

unread,
Mar 24, 2012, 3:44:19 PM3/24/12
to silverst...@googlegroups.com
While the redesign is an important part, it's only part of this project - we're looking for overall improvements and we've already had some good suggestions in other threads. So I'm looking forward to yours - you have got time until the 6th of April :-).

Cheers,
Philipp

Ingo Schommer

unread,
Mar 25, 2012, 7:08:31 AM3/25/12
to silverst...@googlegroups.com
Hey Vivek, please make sure to read Andrew Short's post on the module ecosystem.
There's strong dependencies between the underlying work (Composer, autoloading),
as well as the interface.

The way I see it, a successful project idea to improve
the user experience and functionality on silverstripe.org
has to either incorporate the "base work" that Andrew is suggesting,
or find a smart way to work on top of it (and more or less in parallel).

A decision for or against using Packagist will be central to this effort,
so it'd be good to evaluate how difficult it will be to fit our feature
ideas into their codebase (its a Symfony project), ideally before
the student application period is in full swing.

Ingo

Vivek Pradhan

unread,
Mar 26, 2012, 1:53:23 AM3/26/12
to silverst...@googlegroups.com
Thanks a ton Ingo and Philip, I checked the other threads exp Andrew Short's post on the module ecosystem
and it really gave me an insight on how the module system is actually going to work.


So this is what i have gathered so far. Please correct me if i am wrong anywhere

1> We will store the modules 'metadata' in a composer.json object rathern than an xml or yaml file which defintely looks like the way to go. Beacuse the composer.json has a lot of attributes which can help us query the right results for the user. Like the keywords attribute, when the name of the  module is not that suggestive of what it does. keeping track of comments so that searchiing can be improved further sounds a little cumbersome. Composer object is an amazing thingy and its versatile scripts can
help us connect to the UI seamlessly. because i haven't been involved in silverstripe developmentt before, i want to know how is the same thing done right now. So that we can decide if we want to completely revamp the basic file storage and stuff or just work on improving the Ui.

2> As far as the UI is concerned, it is a little boring at present(ps: no offence ;))

   I mean it has got all the necessary thingies it needs..the info is all there. But i think it can be organised a little bit better with some tweaks ofcourse. The search bar takes up the larger part of the page in the first look
i think it should be minimal with only few options like may be the suggested by option.
the other things are taken care of below

a>I checked the test module http://ssmods.com developed by mr nicholas. And 2 additions are really important. First a most downloaded section which lists the top 10 downloaded modules(again that can be filtered by daily,monthly or all the time) depending 
upon the complexity or the utter requirement of this.  


b> there should be a categories section that lists the categories of the modules like social integration, SEO, ecommerce ,image slider and stuff. These categories should definitely be a part of the keywords thingy in the composer.json(its obvious)


c>It is really important that we show the user the shear enormity of the modules page. It helps in its growth trust me. I mean as should as somebody sees the modules page he should be like damn thats a LOT OF modules and the total number of downloads should also be listed like in the word press plugins  page. Similarly even while showing the categories it should show the number of modules in brackets. A CLOUD of categories can be accomodated easily in a small space and it can give the users both the infos.
Now when the user clicks on a category,like in here  http://ssmods.com there should be thumbnails rather than listing them so that the user has to scroll down. Thumbnails show a lota information to the viewer

d> If the user has found a specific module..the info we show about the module right now is good but not sufficient.
we can implement an activity stream sorta thingy that shows a change log or the improvements in the modules with time or a time line sort of thing.

e> I think when the user clicks on the installation steps, he should not be redirected to another page rather the instructions should be shown there(basic ajax). The idea is to keep the flow of information really simple so that the user can navigate his way around and find stuff relevant to him

f> the comment and rate section. Rating can be done out of 3 or 5 and it can be shown below the rating how many people found it working satisfactorily and how many reported it broken..just a number. A user can rate only if he is logged in. And the rating should be improved and/ or refreshed upon update of a module.  A logged in user can not rate multiple times (use a session variable..should be simple)

g> Use of apis to fetch data from Git or may be svn etc also sounds good. Although i do not have much experience in that.

h>Okay last thing. Yes i think it is important that each module page shows the current version of that module if installed on the user's machine. I do not know how to go about it. You all will have to guide me :). This removes the use of compatible with line in the main search bar. Coz many newbies would not even know which version of the silverstripe cms are they using and they would not wana go and look up the dashboard or some file to find the version only so that the search is faster. We should do it for them. The simpler the better..


That is all i got right now. I really need the mentors to tell me how they feel about this. Obviously right now with my knowledge, i can implement some of the things but not all. But with ur valuable input, i would love to learn. This is gona be fun!


Thanks a lot! and sorry for having to made u scroll till down here ;)

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/1r0AwuRL00MJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

Andrew Short

unread,
Mar 26, 2012, 2:18:22 AM3/26/12
to silverst...@googlegroups.com
Hey,

I'm not sure it'll be feasible to implement a download counter, since once composer is integrated I would hope most people would use that rather than downloading the module as an archive. Also the thing where you can check if modules are up to date on the site won't be doable - what you could do is have a /dev/something page which checks if modules are up to date. However, that would be something more on my end, and probably not related to the improve modules/widgets page task.

Andrew Short.

Jakob Kristoferitsch

unread,
Mar 26, 2012, 3:51:10 AM3/26/12
to silverst...@googlegroups.com
Am 26.03.2012 07:53, schrieb Vivek Pradhan:
> h>Okay last thing. Yes i think it is important that each module page
> shows the current version of that module if installed on the user's
> machine.

The installed version data lives in the CMS and not in the user's
browser. I agree that it is important to have that information
available, but it is very hard to get it into the browser. I think this
could instead be handled in the following way:

A page in the CMS Backend that lists the currently installed modules.
Either when this page is visited or when a big "check for Updates"
button is pressed, the currently installed versions are POSTed to
silverstripe.org . The reply contains the newest available versions. The
local installation compares the two versions and shows that an update is
available.

The backend could also show an "update this module" button if a newer
Version is available, but I am not sure if a through the web update is a
good idea. Currently, the root of the site has to be writeable in order
to install modules. I am not sure if it is a good idea to grant the
webserver user the necessary rights.

HTH
Jakob

Vivek Pradhan

unread,
Mar 26, 2012, 10:29:41 AM3/26/12
to silverst...@googlegroups.com
Thank you Andrew and jacob
     As Andrew mentioned implementing current module version installed on a user's cms on his machine is kinda difficult. And as 
     Jacob said it would definitely not work in the user's browser. So we need to tweak with some of the pages in the CMS backend. So that when the user presses an update button or something like that from his dashboard..his installed module's versions can somehow be detected.

As far as the download counter is concerned. I have 2 suggestions Andrew
1> Is it possible to introduce another attribute to the composer object of every module that keeps track of its downloads and get
updated whenever the user clicks on the download button in that module's page?

2> If  <1> is not possoble. Can we somehow bind the number of downloads with the short description in the description attribute of 
the composer object. Its all a string. So when a user clicks on download, we can simply extract the numbers out of the description 
string from the composer json object and update its value by 1. i tried to do this with javascript. It was prety trivial. 

Do you think this can work? coz if it is about storing a large number(that is the downloads) in the composer object and then updating the json object when the user clicks on download button, i think it can be achieved.

Please let me know how am i approaching the problem? i would love to hear ur suggestions for further improvement so that 
i can have an idea of how to go about the whole thing and apply for the project as soon as possible! :)

Thanks guys 


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverstripe-dev@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.

Ingo Schommer

unread,
Mar 26, 2012, 11:02:22 AM3/26/12
to silverst...@googlegroups.com
The composer.json file lives in the source code repository of the module,
to which ss.org doesn't have commit access (and wouldn't want to clutter
with download counter commits either way).

Composer has already solved the problem of determining outdated versions.
php composer.phar update --dry-run (and the related PHP APIs).
Any UI (such as marking outdated modules) should always build on this base layer.

I think to further the discussion, it'd be good to get to know the composer.lock file,
as this will be an important part of the upgrade logic:
http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file

On a more general note, Packagist uses a packages.json file which aggregates
all the composer.json's from individual modules ("packages"),
so we could expose additional data this way without altering the original composer.json's:
http://getcomposer.org/doc/05-repositories.md#composer
See it in all its beauty here: http://packagist.org/packages.json (careful, large)
The packages.json can be auto-generated as well: http://getcomposer.org/doc/articles/handling-private-packages-with-satis.md


On Monday, 26 March 2012 at 4:29 PM, Vivek Pradhan wrote:

> Thank you Andrew and jacob
> As Andrew mentioned implementing current module version installed on a user's cms on his machine is kinda difficult. And as
> Jacob said it would definitely not work in the user's browser. So we need to tweak with some of the pages in the CMS backend. So that when the user presses an update button or something like that from his dashboard..his installed module's versions can somehow be detected.
>
> As far as the download counter is concerned. I have 2 suggestions Andrew
> 1> Is it possible to introduce another attribute to the composer object of every module that keeps track of its downloads and get
> updated whenever the user clicks on the download button in that module's page?
>
> 2> If <1> is not possoble. Can we somehow bind the number of downloads with the short description in the description attribute of
> the composer object. Its all a string. So when a user clicks on download, we can simply extract the numbers out of the description
> string from the composer json object and update its value by 1. i tried to do this with javascript. It was prety trivial.
>
> Do you think this can work? coz if it is about storing a large number(that is the downloads) in the composer object and then updating the json object when the user clicks on download button, i think it can be achieved.
>
> Please let me know how am i approaching the problem? i would love to hear ur suggestions for further improvement so that
> i can have an idea of how to go about the whole thing and apply for the project as soon as possible! :)
>
> Thanks guys
>
>
> On Mon, Mar 26, 2012 at 1:21 PM, Jakob Kristoferitsch <ja...@kristoferitsch.name (mailto:ja...@kristoferitsch.name)> wrote:
> > Am 26.03.2012 07:53, schrieb Vivek Pradhan:
> >
> > > h>Okay last thing. Yes i think it is important that each module page
> > > shows the current version of that module if installed on the user's
> > > machine.
> >
> >
> > The installed version data lives in the CMS and not in the user's browser. I agree that it is important to have that information available, but it is very hard to get it into the browser. I think this could instead be handled in the following way:
> >

> > A page in the CMS Backend that lists the currently installed modules. Either when this page is visited or when a big "check for Updates" button is pressed, the currently installed versions are POSTed to silverstripe.org (http://silverstripe.org) . The reply contains the newest available versions. The local installation compares the two versions and shows that an update is available.


> >
> > The backend could also show an "update this module" button if a newer Version is available, but I am not sure if a through the web update is a good idea. Currently, the root of the site has to be writeable in order to install modules. I am not sure if it is a good idea to grant the webserver user the necessary rights.
> >
> > HTH
> > Jakob
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

> > To post to this group, send email to silverst...@googlegroups.com (mailto:silverst...@googlegroups.com).
> > To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com (mailto:silverstripe-dev%2Bunsu...@googlegroups.com).


> > For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>
>

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

> To post to this group, send email to silverst...@googlegroups.com (mailto:silverst...@googlegroups.com).
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com (mailto:silverstripe-d...@googlegroups.com).

xeraa

unread,
Mar 26, 2012, 6:57:53 PM3/26/12
to silverst...@googlegroups.com
Just to make sure: Vivek you want to update the module page, right? Because I got the feeling that part of the discussion started to drift off to the module manager part.

As I've said in another thread, I really like the idea of having wireframes (nothing fancy, focus on the functionality) for this as it's much easier to show rather than to describe. Ideally you can keep that in sync with the ideas for the module manager and can then define:
* This is stored at ss.org (ratings for example)
* This is fetched via Packagist / Composer (and possibly stored at ss.org as well for the search functionality)
* This is fetched from GitHub / SVN directly
* We provide the following search / order by features
* ...

Cheers,
Philipp

Andrew Short

unread,
Mar 26, 2012, 7:12:05 PM3/26/12
to silverst...@googlegroups.com
Just one quick note - it'd be best to avoid directly interacting with VCSs is possible, since Composer abstracts this so you can use git/hg/svn, and implementing info retrieval from all thes would be non-trivial and hard to maintain, especially if Composer adds new features.

Andrew Short.



--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/PUyXh9SV8qIJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

xeraa

unread,
Mar 26, 2012, 7:17:08 PM3/26/12
to silverst...@googlegroups.com
Just one quick note - it'd be best to avoid directly interacting with VCSs is possible, since Composer abstracts this so you can use git/hg/svn, and implementing info retrieval from all thes would be non-trivial and hard to maintain, especially if Composer adds new features.

My bad, it should have been only GitHub (without SVN - not sure how to cover it for that) - I assume there's no wrapper for issues, wiki pages,... - right?

Cheers,
Philipp

Sam Minnée

unread,
Mar 26, 2012, 7:18:39 PM3/26/12
to SS Dev
Yes - IMO we should have exactly one way of getting a module into the repository: "Please provide the URL of the repository where the Composer package is located"

Vivek Pradhan

unread,
Mar 26, 2012, 11:50:08 PM3/26/12
to silverst...@googlegroups.com
Thanks a lot for ur input Phillip.

Its just that i thought that something that shows the total number of downloads for a particular module will be good. So i went 
into implementing that. I really appreciate Ingo giving me those references, They will really come in handy. 

But yes, I want to update the modules page, so i should not really think about the how the modules are managed right now.
Yes, I understand you want it to be simple. I will work on some basic design which reflect what i want 
from the modules page i.e how the functionality is made easier for the user so that he gets all the information he wants and
can navigate his way around the modules page. That has been my idea all along but thanks for telling me what exactly u want.


I will get done with some wire frames asap and mail them to you. 

Thanks again.

Vivek Pradhan

unread,
Mar 27, 2012, 6:50:45 AM3/27/12
to silverst...@googlegroups.com
hey there,  I am attaching the module_wireframe with this post. I would be glad if the mentors could tell me where i went wrong
and what did i miss. I would love to improve it. i have given some ideas i had.

I have one question though. One of the objectives of this idea is to allow easier updates to ones own module/widget. 
I mean if somebody is working on a fork or some update. He can give the link to the git fork in the activity stream..
I did not understand in what sense are we talking about here? And how is that indicated to the infrastructure of the modules and
widgets page?


Thanks again!
module_wireframe.pdf

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 27, 2012, 7:25:19 AM3/27/12
to silverst...@googlegroups.com
some great ideas

Vivek Pradhan

unread,
Mar 27, 2012, 9:17:59 AM3/27/12
to silverst...@googlegroups.com
Thanks a lot Nicolaas. 
i checked the page u built for module and widget framework testing http://ssmods.com/. It was great. I took up a lot of inspration from it. Please suggest any improvements that can be further done on the basic idea that i propsed. 
 And if you don't mind me asking, U will be mentoring this project right?


Thanks a lot for your feedback :)

On Tue, Mar 27, 2012 at 4:55 PM, Nicolaas Thiemen Francken - Sunny Side Up <ma...@sunnysideup.co.nz> wrote:
some great ideas

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 27, 2012, 4:05:23 PM3/27/12
to silverst...@googlegroups.com
On 28 March 2012 02:17, Vivek Pradhan <sasuke...@gmail.com> wrote:
> Thanks a lot Nicolaas.
> i checked the page u built for module and widget framework
> testing http://ssmods.com/. It was great. I took up a lot of inspration from
> it. Please suggest any improvements that can be further done on the basic
> idea that i propsed.
>  And if you don't mind me asking, U will be mentoring this project right?

Yes, I would like to.

xeraa

unread,
Mar 27, 2012, 7:57:31 PM3/27/12
to silverst...@googlegroups.com
Hi Vivek,

hey there,  I am attaching the module_wireframe with this post. I would be glad if the mentors could tell me where i went wrong
and what did i miss. I would love to improve it. i have given some ideas i had.

Some great ideas there!
However, I find it pretty text heavy and they're not wireframes (https://en.wikipedia.org/wiki/Website_wireframe). While you're definitely not required to produce wireframes, I find them very helpful in communicating your ideas clearly.
 
I have one question though. One of the objectives of this idea is to allow easier updates to ones own module/widget. 
I mean if somebody is working on a fork or some update. He can give the link to the git fork in the activity stream..
I did not understand in what sense are we talking about here? And how is that indicated to the infrastructure of the modules and
widgets page?

At the moment, you fill out a form and someone at ss.org accepts your module and publishes it. However that process is a little tedious, especially for updates.
In the new system, the information should be extracted from a file inside the repository and you only need to post the URL to your repository. Updates could then be fetched automatically from your (revisioned) file.
I assume initial submissions must be accepted by someone at ss.org to avoid crap entries. However, I'm not sure what the plan for updates is.
IMHO your module will also need to handle that clearance process.

With forks it gets a little more complicated. As long as the module is still maintained, forks should get their changes into the original repo via pull requests. So no change on our side is required.
However, if a module is abandoned, we might need to introduce some transfer mechanism (change the base URL to a new location and retrieve the information from there from now on).
If someone creates a competing fork, he will need to enter it himself, as both the old and the new version will need to be listed (but I hope this only happens rarely).

Hope this answers your question :-).

Cheers,
Philipp

Vivek Pradhan

unread,
Mar 28, 2012, 9:17:23 AM3/28/12
to silverst...@googlegroups.com
Thanks a lot Phillip

Sory for all the text u had to go through. i just wanted to put my ideas clearly. But i will keep ur advice in my mind.

I checkd out http://www.silverstripe.org/modules/manage/add. There it says, to change an already accepted module on the silverstripe site, the creator can edit it from the link of the module on his profile page. The changes to an already accepted module
will come into effect directly.Does this mean, the user has to fill out the submission form again will all the files so that the module is
updated?

Correct me if i am wrong but u want the user to just upload the one file that has been modified into the specific url of the repository so that the module is updated. Should that not be a part of the module manager rather than the modules index page? I am a little confused about how is it gona work?

Or do u want it to be something like when a logged in user browses to the module page of his own module. There should be an update existing version that allows the above functionality?


Thanks a lot for ur help


Cheers,
Philipp

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/TZd7FjFw4cMJ.

xeraa

unread,
Mar 28, 2012, 10:55:18 AM3/28/12
to silverst...@googlegroups.com
Hi Vivek,
 
I checkd out http://www.silverstripe.org/modules/manage/add. There it says, to change an already accepted module on the silverstripe site, the creator can edit it from the link of the module on his profile page. The changes to an already accepted module
will come into effect directly.Does this mean, the user has to fill out the submission form again will all the files so that the module is
updated?

Great that you took a look at it!
Actually you can see the existing module and edit the information, which is already there.
However, in the future that should be extracted from the repository file. So there's no editing form required and the initial creation would be to provide the URL to the repository.
 
Correct me if i am wrong but u want the user to just upload the one file that has been modified into the specific url of the repository so that the module is updated. Should that not be a part of the module manager rather than the modules index page? I am a little confused about how is it gona work?

No upload - you just provide the URL and the file with the information is fetched automatically :-). We still need to define how you'll interact with the module manager and who's responsible for what, but we can do that a little later - I think the overall approach is more or less clear now. Or do you have any additional questions?
 
Or do u want it to be something like when a logged in user browses to the module page of his own module. There should be an update existing version that allows the above functionality?

IMHO the file would be fetched once a day or week and if it has changed, we would try to update the information.

Cheers,
Philipp 

Vivek Pradhan

unread,
Mar 28, 2012, 11:05:48 AM3/28/12
to silverst...@googlegroups.com
Thanks a lot Phillipp

U cleared out a lot of doubts that i had.

Thats exaclty what i wanted to know how the module manager would interact with the user
when he/she wants to update the module they created.

But like u said.. we can worry about it a little later. yes the idea is a lot
clearer now and it makes sense to me now. i just wanted to have an idea on how do u wish to achieve the all the objectives that u have mentioned for this infrastructure project. Now i do. 

And thank you so much for ur guidance. I really needed that. I wil definitely get back to u, if i have any other doubts regarding this project before i apply for this propsal with GSOC.


u are a great help

Cheers :)  



Cheers,
Philipp 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/a3b4PFp2HfAJ.

xeraa

unread,
Mar 28, 2012, 7:43:49 PM3/28/12
to silverst...@googlegroups.com
You're most welcome - feel free to post any upcoming questions and we'll try to work them out.

Cheers,
Philipp

Ingo Schommer

unread,
Apr 15, 2012, 5:56:16 AM4/15/12
to silverst...@googlegroups.com
Hello Vivek, 

thanks for your application! And sorry for the lack of feedback on it,
the core team is fairly busy getting 3.0 beta2 out of the door at the moment!

I've just responded to Vikas who is applying for the same project idea,
with some further considerations that might be of interest to you as well:

All the best
Ingo

Vivek Pradhan

unread,
Apr 16, 2012, 2:48:36 AM4/16/12
to silverst...@googlegroups.com
Thanks a lot for getting back to me Ingo. I will surely take a look at the thread and try to improve upon my ideas

Cheers


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Uj8DU9M90FMJ.

Vivek Pradhan

unread,
Apr 16, 2012, 9:05:41 PM4/16/12
to silverst...@googlegroups.com
Hey Ingo,

i checked out https://groups.google.com/forum/#!msg/silverstripe-dev/iYmT1tJlb-E/EYY7PaZQlNwJ and some other references I found on other threads relevant to the modules project and I have some questions

U said we need to improve the automated testing for every module which makes sense because it makes debugging a hell lot easier. The phpunit framework is amazing for writing unit tests and function test and I think I have some idea of how it works. So I am working on writing some tests for some specific modules so that I can see them in action.

So, we want to have a good test coverage for all the modules. But how do we integrate it to the modules and widgets page?
As in, do we allow logged in users to submit tests for a specific module? Is it supposed to be like, can anyone run any test for any module once they are logged in? How is it gonna work?


As far as the comments and feedback section is concerned. I have proposed that people can comment by providing their email id and may be a sort of a nick name, I tried to refrain from social integration of the comments section but disqus sounds like a great option now that I think about it. I think its a tool that is tailor made for discussions on websites and its got a great interface and I think it can be integrated into the page easily.

And don't you think if we have a separate website altogether for the modules and widgets for silverstripe.org, the overall implementation of the ideas that we all have come up with will be  a little more challenging? I mean I submitted my proposal keeping in mind that the updation or integration of new things into an already existing modules and widgets page sounds simpler.
What do you think about this?

Will Rossiter

unread,
Apr 17, 2012, 1:42:41 AM4/17/12
to silverst...@googlegroups.com
I mean I submitted my proposal keeping in mind that the updation or integration of new things into an already existing modules and widgets page sounds simpler.

The new modules / extensions site will be started with what is currently live so you won't be starting on a blank slate. 

Vivek Pradhan

unread,
Apr 17, 2012, 8:37:40 AM4/17/12
to silverst...@googlegroups.com
Thanks a lot for your quick reply Will. I got your point. It makes sense. I went through https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/okskE6R4ZQI , so I gather there will be a separate modules/extensions site most probably. I will keep track of the thread.

i would really appreciate if you could give me some idea of how are we going to integrate module testing framework into the modules page?  (I am talking about both front end and back end)

Cheers!

On Tue, Apr 17, 2012 at 11:12 AM, Will Rossiter <will.r...@gmail.com> wrote:
I mean I submitted my proposal keeping in mind that the updation or integration of new things into an already existing modules and widgets page sounds simpler.

The new modules / extensions site will be started with what is currently live so you won't be starting on a blank slate. 

On Tue, Apr 17, 2012 at 1:05 PM, Vivek Pradhan <sasuke...@gmail.com> wrote:
I mean I submitted my proposal keeping in mind that the updation or integration of new things into an already existing modules and widgets page sounds simpler.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

xeraa

unread,
Apr 17, 2012, 6:51:08 PM4/17/12
to silverst...@googlegroups.com
Hi Vikas,
 
U said we need to improve the automated testing for every module which makes sense because it makes debugging a hell lot easier. The phpunit framework is amazing for writing unit tests and function test and I think I have some idea of how it works. So I am working on writing some tests for some specific modules so that I can see them in action.

There are already many unit tests in SS core and modules - you can run them to see PHPUnit in action.

So, we want to have a good test coverage for all the modules. But how do we integrate it to the modules and widgets page?

IMHO this was about testing your code - it's not the scope of this project to (automatically) test the modules / widgets.
 
As in, do we allow logged in users to submit tests for a specific module? Is it supposed to be like, can anyone run any test for any module once they are logged in? How is it gonna work?

I don't think we want to integrate any form of continuous integration into the module. We just want to have a good coverage of it.
If people want to add tests for a module, that would be handled via a pull request on GitHub.

As far as the comments and feedback section is concerned. I have proposed that people can comment by providing their email id and may be a sort of a nick name, I tried to refrain from social integration of the comments section but disqus sounds like a great option now that I think about it. I think its a tool that is tailor made for discussions on websites and its got a great interface and I think it can be integrated into the page easily.

I'd assume this would be handled much like in the documentation. Take a look at http://doc.silverstripe.org/sapphire/en/topics/security for example at the bottom of the page.
 
And don't you think if we have a separate website altogether for the modules and widgets for silverstripe.org, the overall implementation of the ideas that we all have come up with will be  a little more challenging? I mean I submitted my proposal keeping in mind that the updation or integration of new things into an already existing modules and widgets page sounds simpler.
What do you think about this?

It's definitely a bigger challenge, but as discussed in another thread, it's deemed worth it. We want to have a long term solution. We won't overwhelm you with the changes needed for that.

Cheers,
Philipp 

Vivek Pradhan

unread,
Apr 18, 2012, 2:46:51 AM4/18/12
to silverst...@googlegroups.com
Thanks Phillip,

i am Vivek :P

I will try out some tests in SS modules to get a better understanding of how phpUnit works.

And ya that is exactly what i wanted to know. I mean there would be a space where people could submit tests for a specific module and may be the link could be provided on the page of each module. So that they will be redirected straight away to the specific page where they can have a pull request from github and the test is submitted into the specific directory.

And thanks for clarifying the automated testing thing. I got that wrong. There is no way we can automatically test a module against all the relevant tests submitted. Does not make sense.

And as far as the comments and feedback section is concerned. I looked at http://doc.silverstripe.org/sapphire/en/topics/security. It looks great and simple. I got an idea of how do you want it to look on the modules page. 

Thanks again Phillip

Cheers!



--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/T-DjKcSD9kEJ.

xeraa

unread,
Apr 18, 2012, 5:52:54 PM4/18/12
to silverst...@googlegroups.com
i am Vivek :P

Sorry, shouldn't write emails in the middle of the night...
 
I will try out some tests in SS modules to get a better understanding of how phpUnit works.

And ya that is exactly what i wanted to know. I mean there would be a space where people could submit tests for a specific module and may be the link could be provided on the page of each module. So that they will be redirected straight away to the specific page where they can have a pull request from github and the test is submitted into the specific directory.

I think we're talking about the same thing, but you make it sound more complicated than it is:
Unit tests are implemented in test-classes within each module, so they are part of the (GitHub) code - let's ignore SVN oder other Git accounts for the moment.
We link to the GibHub account (where the code is); everyone wanting to add tests can clone the project on GitHub, add the tests in his cloned repository and provide a pull request with his changes to the original account. So besides linking to the module's code, there is IMHO nothing more we need to do - everything else happens within GitHub's ecosystem.

And thanks for clarifying the automated testing thing. I got that wrong. There is no way we can automatically test a module against all the relevant tests submitted. Does not make sense.

And as far as the comments and feedback section is concerned. I looked at http://doc.silverstripe.org/sapphire/en/topics/security. It looks great and simple. I got an idea of how do you want it to look on the modules page. 

Great!

Cheers,
Philipp 

Sam Minnée

unread,
Apr 18, 2012, 5:59:03 PM4/18/12
to silverst...@googlegroups.com
On 19/04/2012, at 9:52 AM, xeraa wrote:

i am Vivek :P

Sorry, shouldn't write emails in the middle of the night...
 
I will try out some tests in SS modules to get a better understanding of how phpUnit works.

And ya that is exactly what i wanted to know. I mean there would be a space where people could submit tests for a specific module and may be the link could be provided on the page of each module. So that they will be redirected straight away to the specific page where they can have a pull request from github and the test is submitted into the specific directory.

It might be worth looking at some of the existing modules such as blog to see how it all fits together:


Note that the tests extend SapphireTest, which is a subclass of the PHPUnit testclass class that all SilverStripe tests should extend.  The primary purpose of SapphireTest is to assist with the creation of fixtures, but it also has set-up and tear-down methods to ensure that tests don't trip over global state too much.

There are quite a few docs on testing here http://doc.silverstripe.org/sapphire/en/topics/testing/
Reply all
Reply to author
Forward
0 new messages