--To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/1r0AwuRL00MJ.
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.
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.
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
--
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.
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).
--
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.
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.
some great ideas
Yes, I would like to.
hey there, I am attaching the module_wireframe with this post. I would be glad if the mentors could tell me where i went wrongand 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 andwidgets page?
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.
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 modulewill 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 isupdated?
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?
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.
--
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.
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.
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.
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?
--
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.
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.
i am Vivek :PSorry, 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.