Page Index Toggle Pages: 1
Topic Tools
Normal Topic YaBB Next Code-i-festo + Roadmaps (Read 2,889 times)
JonB
YaBB Administrator
YaBB Next Team
Operations Team
Beta Testers
Support Team
*****
Offline



Posts: 3,785
Location: Land of the Blazing Sun!

YaBB 2.6.0
Re: YaBB Next Code-i-festo + Roadmaps
Reply #1 - Nov 2nd, 2012 at 4:22pm
Post Tools
RoadMap 01.4 - 2.5.2 to 2.6

The primary goal of the next two releases will be to get YaBB Next into a single development track.  The YaBB Next Team will NOT be jettisoning all the progress that was made in development of YaBB 3.0 and those branches.

Where possible, ideas and code will be brought into the new branch. In some cases, the ideas will be preserved, although the code may be re-styled.  YaBB is built by standing on the shoulders of those who went before. The way forward is also inclusive, we will have room for both the YaBB interest-focused small forums that love its openness, and those that require scalability and integration for larger venues.

In the subsequent Roadmap, we will show the way to a YaBB that preserves flatfile and opens the YaBB world to MySQL without huge compromises. We also have many, many new ideas in the works.  Some need think-throughs, others need research - in either case, they aren't quite ready for much beyond 'maybe we can ...'  Wink

We have attached both a PDF Document and a viewable PNG file

Keep trucking Yabbers!

Thanks
The YaBB Next Team
Cool
  

RoadMap_01_4_001.pdf ( 127 KB | 186 Downloads )
RoadMap_01_4_001.png ( 161 KB | 253 Downloads )
RoadMap_01_4_001.png

I find your lack of faith disturbing.
Back to top
IP Logged
 
JonB
YaBB Administrator
YaBB Next Team
Operations Team
Beta Testers
Support Team
*****
Offline



Posts: 3,785
Location: Land of the Blazing Sun!

YaBB 2.6.0
YaBB Next Code-i-festo + Roadmaps
Oct 31st, 2012 at 10:47pm
Post Tools
As we all thought about the future of YaBB, and then worked on YaBB 2.5.2 - there has been an ongoing conversation about 'how we get there'.  Dandello and JonB have been discussing this for some months. When Corey was persuaded to give us a chance to start re-building YaBB, he became part of this dialogue.  Others have seen drafts and have given feedback.  Much work and re-thinking have gone into this effort.  The long term outcome is 'How to have your YaBB and eat MySQL too.'

The Code-i-festo describes the process and methods. The Roadmaps describe an event pathway.

YaBB Next Team Code-i-festo

Introduction:

Many have asked for, or thought about 'Automatic Updates', a 'zero-defects', user friendly web installer (a la WordPress), plus simplified and more reliable methods of delivering 'Mods' to admins/webmasters (BoardMod++).  All of those things rely on high levels of code discipline to make them do-able.

In the same vein, YaBB's early success was that is was 'approachable' and 'accessible' for novices.  You didn't need an engineering degree to make improvements.  These two sets of objectives would seem to be at odds. The YaBB Next team sees it as a 'process challenge'. In the end, it's really only the user interface that folks really want to modify - so we have to keep 'that YaBB' accessible and 'Perl hacker' & Template developer friendly.  This means structured, understandable Procedural Perl, and Modular CSS.

There are also parts of YaBB (the plumbing/internals) where OO Methods or Procedural Perl, or Perl Modules are all OK. No one really cares 'how' a better Admin & User Dashboard is developed, or what the guts of a Moderation System would be. When you get to concepts like an API - you would have to say 'a task for OO methods'. The end-users of the forums and Admins flatly do not care how you build that part of YaBB. They just want it to work and be 'accessible' and 'logical'.  Obviously, these two worlds are joined by YaBB's own nomenclature and tags.

To do that we need a description of the processes + roadmaps to keep us on track. This code-i-festo and the roadmaps being released are evolutionary documents, subject to update and improvement.

The Goods/How-to's:

This is a guideline for both 'The Great Code Restructuring' and all subsequent new code post YaBB 2.5.2

Clarifications:
Use of the words - Mod, Module, module
     Mod - A modification or addition to YaBB that serves a specific function within the Core. Keyword is functionality. They usually modify other exisitng scripts.
     Module, module - A complete object or process that has its own code container(s) and data.  
     Extension - A Module that adds a complete new subsystem. Examples - Member Map, Event Calendar etc

Perl Styling Terms:
     Procedural or Process-oriented describe modular, linear Perl.

Common Standards Reference
     Perl Best Practices by Damian Conway.
     
General Methodologies -
     Code (where possible) should use strict. Restructured code should be re-written with that objective in mind.
     Short Mainlines in modules
     No recursive modules
     Use local variables, return values in YaBB Tags
     Configuration data should be moved to configuration files
           The filenaming convention is under discussion; .ini, .conf, etc.
     
Perl Styling -

     YaBB Core (Interface)
           Procedural Perl OK, OO Perl - not
           Spaghetti code - Bad Bad
           Use of code hooks for YaBB Mods
           No inline graphics, fixed elements
           
     YaBB Internals (Non-interface elements)
           Procedural or OO Perl OK
           If required, should have their own CSS.

     Overall Perl style/tools
           All Perl code run through Perl Tidy - no hard tabs, no trailing spaces
           Non-interpolated strings properly bracketed with '' or q{} or q~ ~
           Interpolated strings properly bracketed with "" or qq~ ~ or qq{} (choose your brackets to avoid having to escape characters that are *not* meta characters like '\n')
           Redundant code turned into subroutines, subroutines used in multiple files should be moved to Subs.pl (extension of 'no spaghetti code' rule)
           Code should closely adhere to Perl Best Practices, with some acceptable exceptions:
                 newlines within html markup and javascript markup where the markup within Perl is unavoidable
                 grep/map in Boolean or void context (Some experts note that prohibiting these may be a premature optimization.)
                 Excessively complex code should be avoided.
                 Cascading if/elsif chains should be refactored and/or converted into hash lookups where possible.
                 Deeply nested code should also be avoided where possible.
     
File Naming for Perl Scripts and Modules
     .pl - launchable, independent Perl Scripts (procedural Perl)
     .pm - Perl Modules (CPAN style)
     .pod - Plain Old Documentation
     These two classes are ideas to better clarify things.
     .ppm   Procedural Perl Modules (YaBB currently styled procedural Perl -- now .pl files)
     .pom - OO styled callable Perl Module

HTML & CSS Styling
     HTML 5 to be the standard
     Modular CSS throughout.
           The Main refresh (default.html)
                 Container + Body defaults
           Everything else
                 Is zoned by function/layout
                 Inherits
                 Is Self-described

Mod (Modification) Development

     Inline Core Mods
           Add functionality or options to the YaBB user interface.
           Usually are incorporated into existing YaBB modules
           May have datafiles (usually to hold configuration options)
           Procedural Perl only
           No inline CSS Styling, an include should be used.
           Should use Board Mod methods/syntax
           
     YaBB Extensions
           Add a complete new subsystem/feature
           Are self-contanined codewise
           Shoud be read-only against YaBB Core data
           Can be Procedural Perl or OO Perl.
           Should use Board Mod methods/syntax      
           Code,Data, Objects in Folders by ModName under
           {yabb_root}./Modifications/Code(755)
           {yabb_root}./Modifications/Objects(644)
           {yabb_root}./Modifications/Data(644)

Template Development
     HTML 5
     Should have its own CSS styles that use and extend the new modularized YaBB standard nomenclature.
     Current YaBB folder locations for Template structure seem OK



We are releasing this Code-i-festo for all YaBBer's.

Thanks for hanging in there kitties.

The YaBB Team
Smiley
« Last Edit: Nov 2nd, 2012 at 4:21pm by JonB »  

I find your lack of faith disturbing.
Back to top
IP Logged
 
Page Index Toggle Pages: 1
Topic Tools
 
  « Board Index ‹ Board  ^Top