binarycloud-dev

[binarycloud-dev] Future source tree:

[Alex B. <en...@tu...>]

hi all,

This is the source tree I expect we'll have when r2/final is out... I'm sure
some of you will have questions re: this list of classes, etc. Please feel
free.

best,

_alex

Base
---------------------
init
    Init
core
    Auth
    Perm
    Page
    Debug
    Lang
    Request
    Sess
    Err -> PEAR_Error
    
mgr
    EntityManager
    QueryManager
    TemplateManager
    MessageManager
    EventManager
    PolicyManager
    JSRequestManager
    CSSRequestManager
    validators/
        NoTagsValidator
        NoLineBreaksProcessor
        NoEntitiesValidator
        OnlyCharsValidator
        OnlyTagListValidator
        CharsetValidator
        DateValidator
        CurrencyValidator
        DecimalValidator
        IntegerValidator
        TimeValidator
        ZipCodeValidator
        PhoneNumberValidator
        EmailAddressValidator
        PasswordValidator
        CountryValidator
        StateValidator
        FASTASequenceValidator
        .... suggestions here?
    processors/
        CharsetProcessor
        RegexProcessor
        RemoveEntitiesProcessor
        EncodeEntitiesProcessor
        RemoveTagsProcessor
        AllowOnlyTagListProcessor
        TrimProcessor
        RemoveLineBreaksProcessor
        AddLineBreaksProcessor
        AllowOnlyCharListProcessor
        FormatDateProcessor
        FormatCurrencyProcessor
        FormatPhoneNumberProcessor
        FormatCountryProcessor
        FormatStateProcessor
        .... suggestions here?
bldr
    FormBuilder
    ListBuilder
    WizardBuilder
    TreeBuilder
    CalendarBuilder
    EmailBuilder
    FaxBuilder
    PDFBuilder    
    PageDefBuilder
    .... suggestions here?
    UIControlBuilder
    uicontrols/
        TextBoxControl
        WindowStatusControl
        PasswordControl
        TextareaControl
        MultiTextBoxControl
        PulldownControl
        SelectBoxControl
        RadioButtonControl
        CheckBoxControl
        HrefControl
        ImageControl
        DateControl
        CurrencyControl
        ButtonControl
        TextHeaderControl
        OrderedTextHeaderControl
        ImageHeaderControl
        RowControl
        PaginationControl
        SimpleListControl
        .... suggestions here?
lib
    ClientSniffer
    HTMLMimeMail
    SMTP
    Timer
    XMLUtils
    Webalizer
    Htdig
    LangKeyer
    ...
    
utils
    xml2php
    php2xml
    pk2dir
    processprepend
    installcode
    langkey2string

User
---------------------
conf
    Configuration
    Datasources
    Languages
    Operations
    roles/
        GodRole
        AdminRole
        etc
htdocs
    resources
        images
        js
        css
        edit

lib
    user-specific proprietary libs

mod
    example_module
        ExampleModule
        AnotherExampleModule
        tmpl/
        lang/
        qry/
        ent/
        evt/
        msg/
        js/
        css/
        images/
tmpl
    html
    email
    pdf
    ps
    xml
    wml
    etc..



What we don't need in the source tree:
    user/cache
    user/db
    user/lang
    user/roles
    
    
The build tree:
---------------------
lang_code
    binarycloud
        core
        init
        lib
        mgr
        bldr
    ext
        pear
        metabase
        vagrant
        etc
    htdocs
        resources
        ...
    user
        cache
        conf
            roles
        db
            schema
            before
            dump
            qry
        mod
        tmpl
        ent
        evt
        msg

*Note how the build tree contains many more directories, like ent, msg, etc.
This is because make will use the naming conventions below to move files
from module and other directories into a single location. That means files
must not have naming conflicts, etc - but it keeps the source tree, and the
installation process simple.


Naming 'special' files for processing by make:
---------------------
-Something.ent.xml = entity xml definition

-Something.qry.xml = query xml definition

-Something.form.xml = form xml definition

-Something.list.xml = list xml definition

-Something.wizard.xml = wizard xml definition

-Something.calendar.xml = calendar xml definition

-Something.email.xml = email xml definition

-Something.fax.xml = fax xml definition

-Something.pdf.xml = pdf xml definition

-Something.role.xml = role xml definition

-SomeValidator.php = 'Validator' means this file will be placed in
binarycloud/mgr/validators from a module directory.

-SomeProcessor = 'Processor' means this file will be placed in
binarycloud/mgr/processors from a module directory

-Something.xml.php = this file will be processed from xml to php using
default xml2php rules and written out in the same location in the build tree
with the extension .php.

-Something.lang.xml will be used by LangKeyer at make-time to key in
nagive-language strings into source files.

-Something.lang_code.php (i.e. Something.de.php or Something.en.php) means
the file will replace Something.php in same directory when the language code
is the same as lang_code. Useful for writing the same module that does
different things based on the location/language.

RE: [binarycloud-dev] Future source tree:

[Andreas A. <a.a...@th...>]

Hi Alex,

> This is the source tree I expect we'll have when r2/final is
> out... I'm sure some of you will have questions re: this list of
> classes, etc. Please feel free.

> mod
>     example_module
...
>         js/
>         css/
>         images/

What do you think about putting these into mod/example_module/resources/* To
keep the structure more clear.


> This is because make will use the naming conventions below to move files
> from module and other directories into a single location. That means files
> must not have naming conflicts, etc - but it keeps the source
> tree, and the installation process simple.

Does this mean that each image must have a uniqe name? So module "foo" uses
a image called edit.gif and module "bar" must not have a image called
edit.gif!? Or is this seperated in the build tree?


> -Something.lang.xml will be used by LangKeyer at make-time to key in
> nagive-language strings into source files.
Will this work for js/htc files too? Or will this be processed like

Something.lang_code.js ?


> -Something.lang_code.php (i.e. Something.de.php or Something.en.php)
> means the file will replace Something.php in same directory when the
> language code is the same as lang_code. Useful for writing the same module
> that does different things based on the location/language.

What about media files:

Something.lang_code.gif
Something.lang_code.jpg
Something.lang_code.mpeg
...

Andi

Re: [binarycloud-dev] Future source tree:

[Alex B. <en...@tu...>]

> Hi Alex,
> 
>> This is the source tree I expect we'll have when r2/final is
>> out... I'm sure some of you will have questions re: this list of
>> classes, etc. Please feel free.
> 
>> mod
>>     example_module
> ...
>>         js/
>>         css/
>>         images/
> 
> What do you think about putting these into mod/example_module/resources/* To
> keep the structure more clear.

I was thinking that, and yes I agree.

I'll send an amended list to the list (err)
 
>> This is because make will use the naming conventions below to move files
>> from module and other directories into a single location. That means files
>> must not have naming conflicts, etc - but it keeps the source
>> tree, and the installation process simple.
> 
> Does this mean that each image must have a uniqe name? So module "foo" uses
> a image called edit.gif and module "bar" must not have a image called
> edit.gif!? Or is this seperated in the build tree?

nonono,

we'll have separate subdirectories for each image tree re: a module - but
the above does apply to Validators, etc.

>> -Something.lang.xml will be used by LangKeyer at make-time to key in
>> nagive-language strings into source files.
> Will this work for js/htc files too? Or will this be processed like
> 
> Something.lang_code.js ?

yes, it will work for any file extension, and I should mention that. good
point #2 :)

>> -Something.lang_code.php (i.e. Something.de.php or Something.en.php)
>> means the file will replace Something.php in same directory when the
>> language code is the same as lang_code. Useful for writing the same module
>> that does different things based on the location/language.
> 
> What about media files:
> 
> Something.lang_code.gif
> Something.lang_code.jpg
> Something.lang_code.mpeg
> ...

Same :)

_a

RE: [binarycloud-dev] Future source tree:

[Andreas A. <a.a...@th...>]

Hi Alex,

> Naming 'special' files for processing by make:
> ---------------------
> -Something.ent.xml = entity xml definition
> -Something.qry.xml = query xml definition
> -Something.form.xml = form xml definition
> -Something.list.xml = list xml definition

What do you think about naming the xml.php files in sync with the above?

Something.php.xml

This would fit better name.whatitbecomes.filetype

Andi

Re: [binarycloud-dev] Future source tree:

[Alex B. <en...@tu...>]

yes, I'm going to try and get that done today.

_a

> Hi Alex,
> 
>> Naming 'special' files for processing by make:
>> ---------------------
>> -Something.ent.xml = entity xml definition
>> -Something.qry.xml = query xml definition
>> -Something.form.xml = form xml definition
>> -Something.list.xml = list xml definition
> 
> What do you think about naming the xml.php files in sync with the above?
> 
> Something.php.xml
> 
> This would fit better name.whatitbecomes.filetype
> 
> Andi
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] Future source tree:

[jason <ja...@gr...>]

Re: HTML builders

disclaimer: I just wanted to throw this out, as I have not extensively
researched the possibilities much.

I noticed that TableBuilder wasn't listed in the latest source tree
listing.  This may be a good time to discuss how indepth these builders
will/can be.  Question 1, what is the requirement for the need of a
builder?  The builders you mentioned here all (?) seem to work hand/hand
with other parts of the bc core.  (ex: formBuilder uses entityManager) 
Is there a place for builders that merely simplifies the HTML rendering?
(ie: tableBuilder, headerBuilder, ...)

There is a WOW pretty neat set of classes by Walt A. Boring IV called
phpHtmlLib (http://phphtmllib.sourceforge.net/) which does just this. 
One nice feature this project has is the ability to specify HTML 4.0 or
XHTML when you render your page.

I'm not suggesting that we integrated it into binarycloud;  I simply was
checking it out when I started questioning how extensive the binarycloud
builders will be.

jason


>     FormBuilder
>     ListBuilder
>     WizardBuilder
>     TreeBuilder
>     CalendarBuilder
>     EmailBuilder
>     FaxBuilder
>     PDFBuilder
>     PageDefBuilder
>     .... suggestions here?

Re: [binarycloud-dev] Future source tree:

[alex b. <en...@tu...>]

> Re: HTML builders
>
> disclaimer: I just wanted to throw this out, as I have not extensively
> researched the possibilities much.
>
> I noticed that TableBuilder wasn't listed in the latest source tree
> listing.  This may be a good time to discuss how indepth these builders
> will/can be.  Question 1, what is the requirement for the need of a
> builder?  The builders you mentioned here all (?) seem to work hand/hand
> with other parts of the bc core.  (ex: formBuilder uses entityManager)
> Is there a place for builders that merely simplifies the HTML rendering?
> (ie: tableBuilder, headerBuilder, ...)

Table builder has been "renamed" to listbuilder, because it will take care
of any ordered list of data, from a <ul> up to a big, complex table.

> There is a WOW pretty neat set of classes by Walt A. Boring IV called
> phpHtmlLib (http://phphtmllib.sourceforge.net/) which does just this.
> One nice feature this project has is the ability to specify HTML 4.0 or
> XHTML when you render your page.

I think i've seen this, and to be honest I've never had much use for html
abstraction, except for things like <input> etc.

In some case, advanced tools are necessary (like ListBuilder, FormBuilder).

You are of course welcome to use that lib (the code lookged good to me..)
for anything you do.

> I'm not suggesting that we integrated it into binarycloud;  I simply was
> checking it out when I started questioning how extensive the binarycloud
> builders will be.

Well, the builder's won't ingetrate any html, they'll use default 'external'
templates. Really a builder manages taking a set of data or metadata and
turning it into a useable 'definition' of a bit of presentation.

_a

> jason
>
>
> >     FormBuilder
> >     ListBuilder
> >     WizardBuilder
> >     TreeBuilder
> >     CalendarBuilder
> >     EmailBuilder
> >     FaxBuilder
> >     PDFBuilder
> >     PageDefBuilder
> >     .... suggestions here?
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>