--
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.
1- we can add following extra search filters on search page in
addition to existing ones.
(I) Module categories - like e-commerce, developers module, security
etc.
(II) Sort-By - like most installed, most popular, last build, author,
date, latest etc.
FRONT-END IMPROVEMENT (on particular module and widget page) :
we can add few new sections on module page in-addition to existing
one.
(I) Ranking : 1 to 5 star ranking system .
(III) Current no of issues with this particular module or widget, This
will help developers to directly access the current running issues.
(V) Update module : we can add some method to detect users installed
version of module and accordingly can automatically download and
update users module (like in askubuntu site they give link to debian
packages for automatically install)
(VI) Project information section : This area may contain following
information about module or widget .
(a) Maintenance status : like highly, active .
BACK END IMPROVEMENT :
i am assuming following about existing system.(please correct me
if i am wrong)
(1) All data related to module and widget is coming from GITHUB
server.
(2) Data is not stored internally anywhere on silverstripe.org.
(1) my past experience with drupal development says that using Apache
Solr can be more better than Sphinx. as silverstripe already have
apache solr module then implementing it with silverstripe is not big
task. (also drupal using this for his huge module repository and for
every search related thing in their site )
(1) As i posted on sam's post that improving existing stable system
will be better option than adopting new one. until we are pretty sure
that new system is far better thank existing one but I can only
suggest last decision will be yours .
(3) [ (I) Module categories - like e-commerce, developers module,
security
> etc. ---This is based on some sort of tagging you provide? Would there be a set of
>predefined tags or how would you want to approach this? ] -
I had one plan and I got something similar on the Andrew's Post
(http://groups.google.com/group/silverstripe-dev/browse_thread/thread/
8f9202a7f6a877b/8b66c5eba5b42502?lnk=gst&q=Andrew#8b66c5eba5b42502) .
I was thinking about some kind of info file in root of module
directory. which can store some short of meta tag about module like SS
version required, dependencies, package or group of module it belongs
(it will help us making categories) . Andrew suggesting similar with
composer/packagist in json file format or we can try to do this with
something new approach. implementing it with existing modules can be
painful task. but i am considering it as part of whole idea.
(4) [(II) Sort-By - like most installed, most popular, last build,
author,
> date, latest etc.----
>Sounds good, but I'm not entirely sure if all of that information is easily
>available (for example most installed).
>If a project is hosted on GitHub, you could add the number of forks /
>people watching. ]
we can get no of install by counting no of clicks on download-link of
module , we can relate popularity to the ranking of module and no of
installation .I think we can get the information about the last build
from GitHub.
(5)[>(I) Ranking : 1 to 5 star ranking system .
>Users can log in and rank any project once? ]
we need to think about it because allowing anonymous user to rank may
go into wrong direction. But allowing users to rank projects multiple
times will be better idea.
(6) > (III) Current no of issues with this particular module or
widget, This
> will help developers to directly access the current running issues.
>You would take that information from GitHub or where does it come from?
>On Mar 25, 4:10 pm, Ingo Schommer <ingo.schom...@gmail.com> wrote:
as you suggested in later point that web service call for each module
on each query is not good idea so storing some data about modules on
SS server will be right approach and then creating some
Synchronisation method with actual data stored on GitHub will work
nice . But also we do need to create a method so data on SS server can
update automatically when changes occurs on data stored on GitHub .
(7) >[ (V) Update module : we can add some method to detect users
installed
> version of module and accordingly can automatically download and
> update users module (like in askubuntu site they give link to debian
> packages for automatically install)
>I'm not sure how this would work out from a technical point of view, but
>I'm open for suggestions.]
I do need some deep research on this point but I am pretty sure that
it is possible !
(8) [> (VI) Project information section : This area may contain
following
> information about module or widget .
>(a) Maintenance status : like highly, active .
>What's the metric for that? I assume that would be somewhat similar to the
>status on Google code? ]
we can achieve this on the basis of no of commits , changes in past
few days,months on GitHub .
(9) As i said storing some data on SS server will be good. only then
we can make better indexing in Sphinx or Solr .
(10) > (1) my past experience with drupal development says that using
Apache
> Solr can be more better than Sphinx. as silverstripe already have
> apache solr module then implementing it with silverstripe is not big
> task. (also drupal using this for his huge module repository and for
> every search related thing in their site )
>If there are major advantages to be gained, we can probably talk about
>that. However, someone at ss.org will need to set that up for you, so I
>can't give you a definitive answer for that.
Actually I did some research on Sphinx v/s Solr and there is not
much difference in terms of performance so now I think we should drop
this idea because it needs lots of work and major changes in existing
system. I don't think you guys are ready to change something else
which is not much related to this project idea.
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/-/156Nzz7S6nIJ.
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.
>Sounds good. Any ideas how we could avoid synonyms or different ways of writing, like ecommerce, e-commerce, shop,...? >Do we keep a list of suggested tasks as a best practice and low effort approach or should there be something more >sophisticated?
I am not much sure about right approach but we could have some predefined tags .
>Do we have the number of clicks somewhere (easily accessible from your module)? I honestly don't know by heart how this >is handled.
we can add something like download counter .
>IMHO everyone should only be able to vote once, otherwise you could totally break the system (10 votes for a module >overall, 5 extremely good ones from one person). However, people could probably change their rating later on.
That will be also right approach to implement this idea .
(1) I am attaching wire-frames with mail . So please have a look and send me your feedback
(2) There are many confusions floating around regarding this idea like
what will be the base module for this project?
Are we ready to use composer/packagist or not?
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/-/q_8Xqzo3_4wJ.
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.
(1) Its sure that we will store data like dependencies, meta tags, version compatibility of modules/widget in some file. file may be .json file, .info file (drupal guys using such method) or may be we can use any specific file of module for storing those data about module ( like wordpress using style.css for storing data about themes) .
(2) Now when data stored in one of such files module maintainer will push this file along with other files of module on repository of module (GitHub or Packagist).
(3) Module developers will provide URL of his module repository. system will fetch all data from that repository and then mark it as sandbox project. After confirmation from system Admin (someone who is responsible for approval of new modules) system will create a download page for that module and synchronise with that URL, System will also extract info file of module (system know that which file required for getting information about module), after getting information from info file we can sort, arrange that module in ss.org server.
(4) We can use different URL for subversion or we can implement any method so module/system will look for any specific branch on git for that subversion.
(5) Now when module will update on git repository it should automatically update on ss.org server. We can implement this by GitHub service hooks, so when any changes will occur on repository it will call to our module/system for synchronisation with new data. other option could be to set some cron for looking changes on every module repository and accordingly we can update module data on ss.org server.
(6) System should have ability to create packages of module on ss.org server. it should also have ability to change info file according to changes in module, like new version number etc.
(7) For getting information about number of issues system should have ability to sync with ss.org bug tracking system.
Based on above requirements following task need to be done .
(1) Define structure of info file
(2) Implement method so system can automatically fetch data from url of repository.
(3) Implement method so system can talk to info file.
(4) According to data available in info file create structure of search page. Because many search fields will depend on data provided by info file like dependencies, SS version compatibility.
(5) Create structure of module download page.
(6) Implement method so system can automatically create download pages of module .
(7) Implement method so system can handle data of different branches of same module (for subversion).
(8) Define cron jobs for automatic updates and implement it with system (for automatic updates).
(9) Improve system's module packaging ability .
(11) Arrange existing module database according to new system .
(12) We may need to re-index the sphinx search server according to new data uploaded on ss.org server .
>(6) Implement method so system can automatically create download pages of module .
>Do you mean the detailed view of the module?
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/-/uIAXZ773DVwJ.
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.
--
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/-/EYY7PaZQlNwJ.
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.
https://docs.google.com/openid=0B8utgor20eMdaHdreGtnY3VRVi1MNmkxWjhuT1hBZw
Just for reference, Vikas' proposal is available athttps://docs.google.com/openid=0B8utgor20eMdaHdreGtnY3VRVi1MNmkxWjhuT1hBZw
--
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/-/T0Y4rsdcWeUJ.
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.
3- How we will get code of ss.org for porting our module. As Ingo suggested in other thread (https://groups.google.com/forum/#!topic/silverstripe-dev/okskE6R4ZQI/discussion) to move module page on separate website, UncleCheese is also in favor of this idea .
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.