MozillaWiki

Update:Archive/2.0/Developers: Difference between revisions

Update Discussion

Update:Archive/2.0/Developers (view source)

Revision as of 04:47, 29 April 2007

1,423 bytes added ,  29 April 2007
m
Update:Development:v2.0 moved to Update:Archive/2.0/Developers
 
(29 intermediate revisions by 9 users not shown)
Line 1: Line 1:
[[Update:Home_Page|Update: Home Page]] » [[Update:Development|Development]] »
[[Update:Home_Page|Update: Home Page]] » [[Update:Development|Development]] »


== UMO v2.0 Goals ==
== v2.0 Goals ==
* security
* security
* reliability
* reliability
Line 7: Line 7:
* reputation
* reputation
* communication
* communication
* localization


Using sound teamwork, we will develop a secure, robust, extensible application that will bolster the success of the Mozilla Foundation and the community it supports.
Using sound teamwork, we will develop a secure, robust, extensible application that will bolster the success of the Mozilla Foundation and the community it supports.
Line 56: Line 57:


We will do our best to adhere to the Mozilla coding standards. Since not many Mozilla projects are written in PHP, we have [[Update:Development:Best Practices|developed our own]] where necessary.
We will do our best to adhere to the Mozilla coding standards. Since not many Mozilla projects are written in PHP, we have [[Update:Development:Best Practices|developed our own]] where necessary.
== TODO ==
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/lib/session.class.php lib/session.class.php]
** [https://bugzilla.mozilla.org/show_bug.cgi?id=312629 simple session handler based on sid.]
* lib/auth.class.php
** simple session checker and auth module.
** PEAR::Auth?
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/addcomment.php addcomment.php] - Colin
** form
** spam prevention - '''require login'''
** input validation
* <strike>[http://lxr.mozilla.org/mozilla/source/webtools/addons/addon.php addon.php]</strike>
** <strike>sidebar</strike>
** show compat information
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/history.php history.php] - Colin
** show all past versions - initially done but needs improvement...
** simplify?
* <strike>index.php</strike>
** <strike>make it look more like overview.php?</strike>
* previews.php - Colin
** <strike>Show all Addon previews.</strike>
* ratecomment.php - Colin
** spam prevention '''This needs to be thought about'''.
** <strike>other than that, this is a simple toggle script.</strike>
** <strike>login isn't required for this particular page.</strike>
* search.php
** [https://bugzilla.mozilla.org/show_bug.cgi?id=277851 highlight search results]
** <strike>Create search form based on DB.</strike>
** <strike>Filter inputs.</strike>
** <strike>Document needed options.</strike>
** <strike>Create jump-to for one-result searches.</strike>
* header / footer / style
** Fix key-menu so that it is simplified.  Each app link should be a tab, instead of offering 3 different choices per.
** <strike>Make the search stick out more -- this is a key feature of this site.</strike>
** <strike>Make sure CSS changes work in multiple browsers.</strike>
* addon.class.php
** <strike>Move manual queries in constructor to respective functions (i.e. getLatestVersion() instead of a hard query)</strike>


== Use-cases and Requirements ==
== Use-cases and Requirements ==
Line 80: Line 118:


:How about a "my favorite extensions" section with details of latest versions and comments. Users could then "bookmark" extensions they're interested in, but might not have installed. It could also automatically keep track of extensions installed, and visted but uninstalled extensions (something like Google's My Search History). It might encourage more users to register as it's providing something of value to them. Stats could be used for recomendations. You could also track which extensions are being removed from peoples favorites. --[[User:Sam Hasler|Sam]] 14:25, 17 Jun 2005 (PDT)
:How about a "my favorite extensions" section with details of latest versions and comments. Users could then "bookmark" extensions they're interested in, but might not have installed. It could also automatically keep track of extensions installed, and visted but uninstalled extensions (something like Google's My Search History). It might encourage more users to register as it's providing something of value to them. Stats could be used for recomendations. You could also track which extensions are being removed from peoples favorites. --[[User:Sam Hasler|Sam]] 14:25, 17 Jun 2005 (PDT)
:Heh. No one has written here in awhile.
Maybe I'm missing something, but the main page right now doesn't even have links to look for TB extensions, or extensions for any other Moz apps besides FF. Clicking on the extensions button on the front page automatically takes you into a page showing FF extensions. So... is there no way to get to TB extensions without either going through TB or doing some sort of search?
--[[User:Wjjohnst|DigDug] 22:20 05 Oct, 2006


==== Search By... ====
==== Search By... ====
Line 94: Line 138:
==== Results List ====
==== Results List ====
* Allow ASC or DESC sorting per category via clicking on column header
* Allow ASC or DESC sorting per category via clicking on column header
* Allow user to choose compact or expanded view (expanded is what UMO shows now)
* Allow user to choose compact or expanded view
* Expanded -- Show everything UMO shows now
** Compact -- Show only vital items, all in one row, text-only
* Compact -- Show only vital items, all in one row, text-only
** Expanded -- Show everything UMO shows now
* Give user a link to Download/Install or view Item Home page
* Give user a link to Download/Install or view Item Home page


Line 104: Line 148:


:so, this means we need to use a column-type display for the results.  I'm not sure if that's always good.  Maybe only use it for advanced searches, but quicksearch gets the current-style result list? --[[User:CTho|CTho]] 19:05, 13 Jun 2005 (PDT)
:so, this means we need to use a column-type display for the results.  I'm not sure if that's always good.  Maybe only use it for advanced searches, but quicksearch gets the current-style result list? --[[User:CTho|CTho]] 19:05, 13 Jun 2005 (PDT)
I would go for search results that have an extended result by clicking on an image with the "more" concept. Those extended results would be hidden in DIVs that will be shown bellow the line of the extension summary when the user clicks the "more" image. This is client side or if we want smaller pages we can use AJAX to bring this extended content when needed. --[[User:DonGato|DonGato]] 11:57, 28 Nov 2006 (GMT)


==== Item Home ====
==== Item Home ====
Line 163: Line 209:
:if the user is logged in, can we store this on the server?  What if a user has TB and FX?  Can we save both?  I'd skip app version and just track app/OS, assuming that most people will upgrade. -alanjstr 2005-06-01 14:16 EST
:if the user is logged in, can we store this on the server?  What if a user has TB and FX?  Can we save both?  I'd skip app version and just track app/OS, assuming that most people will upgrade. -alanjstr 2005-06-01 14:16 EST


==== Content outsourced to Wiki ====
==== Supporting Site Content ====
* about UMO...
* About UMO
* Updates / news
* News
* FAQ and support documentation
* FAQ
* Developer policies and guide
* Policy
* Reviewer policies and guide
* Developer policies and guide - Wiki
* Reviewer policies and guide - Wiki


:'''Comments'''
:'''Comments'''
Line 176: Line 223:


:Policies should be read-only, signed off by legal, and posted on the site.  Everything else can be in the wiki. -alanjstr 2005-06-01 14:16 EST
:Policies should be read-only, signed off by legal, and posted on the site.  Everything else can be in the wiki. -alanjstr 2005-06-01 14:16 EST
:I agree with your comments.  Guides, however, are constantly updated and should be placed in a Wiki where they can be maintained.  They are relatively dynamic in nature and placing them in the application itself would be very limiting. -[[User:morgamic|morgamic]]


=== Developers ===
=== Developers ===
Line 381: Line 430:
=== Administrators ===
=== Administrators ===
* Administrators should basically have all the general functionality of all other user groups, with added rights to _all_ records and the ability to edit/bless user accounts.
* Administrators should basically have all the general functionality of all other user groups, with added rights to _all_ records and the ability to edit/bless user accounts.
* It's currently too hard to create new reviewers - it requires receiving an email (the intial request), replying to tell the user to create an account, waiting for the reply, then granting them Editor privileges.  This should be streamlined - maybe just a "Volunteer to be a reviewer" button on the developer pages?  --[[User:CTho|CTho]] 17:58, 4 Oct 2005 (PDT)


=== Systems ===
=== Systems ===
Line 387: Line 437:


== Database Structure ==
== Database Structure ==
=== v1.0 Schema ===
'''v2.0 will be rewritten using [https://update-staging.mozilla.org/~colin/dev/ the existing database structure].'''
Thanks to Colin for helping make the [https://update-staging.mozilla.org/~colin/dev/ v1.0 diagram].
 
Thanks to Colin for drawing up the diagram.


==== Problems ====
==== Known Issues ====
* Lacks proper normalization
* Lacks proper normalization
* Incorrect typing
* Incorrect typing
* Non-optimal indexing
* Non-optimal indexing
* Non-optimal version comparisons
* Non-optimal version comparisons
* Inconsistent nomenclature
* Others... ?
=== v2.0 Schema ===
The [http://oregonstate.edu/~morgamic/umo/umo.png first draft of the v2.0 schema] was drafted at midnight, 05/18.
It was made with [http://www.graphviz.org/ GraphViz]; [http://oregonstate.edu/~morgamic/umo/umo.txt view the source file].
==== Change Log ====
* Removed
** faq - outsource to wiki, bring back later if needed
** feedback_ipbans - user accounts will be required for comment posts, general throttling enabled makes this unnecessary
:::see my comment above regarding registration for comments --[[User:CTho|CTho]] 19:24, 13 Jun 2005 (PDT)
** approvallog - this is replaced by reviews
** downloads - this is just deleted, replaced by singular column in addon_versions (throttling, remote limitations pending of course)
* Added
** sessions - track user sessions with more detail, also ensure sess data integrity
** app_addon_map - mappings between addon versions and app versions, replacing minver/maxver comps with a simpler query
** os_addon_map - mappings between addon versions and operating systems, abstracted to avoid having to hard-code OS id's in UMO application (as in v1.0)
** reviews - per-user/per-os review logs, added N times until approval so each item in queue has a running total of "what has been looked at"
** comments - replaces feedback, and is now mapped to user_id (login required)
** addon_types, addon_type_map - abstracts addon types, so E/T will no longer be hard-coded in UMO application (as in v1.0)
** locales, locale_addon_map - per-addon (not per addon version) locale information to help with international extension or theme searches
:What if they have one XPI for EN and one XPI for FR? -alanjstr 2005-06-01 14:36 EST
:I don't see how you could query for a minver or maxver at all here.  There's only one field, not two for min and max.  There is not table of app versions. -alanjstr 2005-06-01 14:36 EST
*General Changes
** naming consistency
** better normalization (probably too much, and probably not perfect, but it's a start)
** better fits workflow
==== Colin's Comments ====
The schema seems reasonable as it stands, although some changes are likely to be necessary pending the discussion above regarding FAQs etc. and whether they should be part of this site, not the Wiki.


Other points as follows:
These issues will be worked on over time.  They are not, however, so serious that a complete restructuring is required for v2.0.
* It seems comments are per addon version and not per addon? This seems 'wrong' to me.
* Each addon_version should (perhaps) have a an "approved_time" column, so that the "Newest" Extensions are based on approved time rather than than added time (which could be 5 days earlier)


==== Possible Problems with this draft ====
==== Garbage ====
* over-normalization
For fun, here is the [http://oregonstate.edu/~morgamic/umo/umo.png now-obselete  v2.0 db diagram] (05/18).  It was made with [http://www.graphviz.org/ GraphViz]; [http://oregonstate.edu/~morgamic/umo/umo.txt view the source file].
* lack of download spam checking in DB (still could be mitigated with proper app logic)
* requiring login for comments might suck, would require a left-join if user_id stays
* migration will be painful, but it is probably a necessary pain (open for discussion, guys)


== Application Structure ==
== Application Structure ==
; .htaccess : Set up include_path, prepend and append options.
; .htaccess : Set up include_path, prepend and append options.
; commentadd.php : Add a new comment.
; addcomment.php : Add a new comment.
; commentrate.php : Rate an existing comment.
; ratecomment.php : Rate an existing comment.
; comments.php : View comments for an addon.
; css/ : CSS layout and formatting.
; css/ : CSS layout and formatting.
; developers : Developer tools used by developers, reviewers and admins.
; developers : Developer tools used by developers, reviewers and admins.
Line 457: Line 468:
; LICENSE : Application license.
; LICENSE : Application license.
; README : Installation instructions for site developers.
; README : Installation instructions for site developers.
; previews.php : Addon previews.
; rss : Syndicated information for addons based on type and application.
; rss : Syndicated information for addons based on type and application.
; search.php : Search for addons using a simple search, or expand simple search to refine your search.
; search.php : Search for addons using a simple search, or expand simple search to refine your search.
Line 473: Line 485:
** Downloaded .xpi does not match reported size (5)
** Downloaded .xpi does not match reported size (5)
* There is a need client-side to implement better update features for addons, similar to those found in [Software Update].  In particular, hash checking and improved error handling (for errors above) would be great additions.
* There is a need client-side to implement better update features for addons, similar to those found in [Software Update].  In particular, hash checking and improved error handling (for errors above) would be great additions.
== UI Tweaks ==
* Alignment of title / drop-down on 'Search Options' sidebar would look better uniform (columned).
* Blue bar at the top (below 'mozilla update' text) looks incredibly empty, especially towards the right. If it's going to remain empty, perhaps consider moving the search to the right.
* Tabs on home page
** Incredibly plain / square.
** Blue on inactive tabs doesn't really fit with the rest of the UI.
** Perhaps consider using the same style tabs as on the header of this wiki?
Fligtar
canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,043

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/10233...55479"