binarycloud-dev

[binarycloud-dev] binarycloud/base/mod

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

hi all,

what does everyone think about having binarycloud/base/mod/ in the source
tree?
I'm thinking that we're going to have a set of modules that will be required
by certain builders and managers ( the JSRequest and CSSRequest Managers
come to mind)

thoughts?

_a

Re: [binarycloud-dev] binarycloud/base/mod

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

makes sense to me... seems like the best place to put "factory" modules.

jason

alex black wrote:
> what does everyone think about having binarycloud/base/mod/ in the source
> tree?
> I'm thinking that we're going to have a set of modules that will be required
> by certain builders and managers ( the JSRequest and CSSRequest Managers
> come to mind)
> 
> thoughts?

RE: [binarycloud-dev] binarycloud/base/mod

[Andreas A. (Thyrell) <a.a...@th...>]

Hi,

Jepp, sounds good. But only for "required-by-core-modules". Other more
independent but still default suff should go to user/default/mod, I think.

Andi



> makes sense to me... seems like the best place to put "factory"
> modules.

alex black wrote:
> what does everyone think about having binarycloud/base/mod/ in the source
> tree?
> I'm thinking that we're going to have a set of modules that will be
required
> by certain builders and managers ( the JSRequest and CSSRequest Managers
> come to mind)
>
> thoughts?

_______________________________________________
binarycloud-dev mailing list
bin...@li...
https://lists.sourceforge.net/lists/listinfo/binarycloud-dev

Re: [binarycloud-dev] binarycloud/base/mod

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

> Hi,
> 
> Jepp, sounds good. But only for "required-by-core-modules". Other more
> independent but still default suff should go to user/default/mod, I think.

Agreed.

These are modules which should _always_ be static, and required by the
system. I'm thinking things like the module for CSS and JS requests (maybe
images, also...).. etc.

Actually...

Is anyone interested in an ImageRequestManager which would use a static
embed tag like the module embeds:

<bc:image id="SomeImageID" />

the reason I thought of doing this:
    -if people use this 'embed' tag, the make system can use a central image
info repository to build well-formed tags that include alts, the _real_
width and height of an image, etc. Of course we could allow overrides:

<bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" />

but in general you'd just use the simple tag.

I can imagine that being convenient for me... would it be convenient for
anyone else?

The xml would probably look like:

<!-- binarycloud image repository example file -->
<!--
used in conjunction with:
    <bc:image id="SomeImageID" />
-->
<images>
    <image>
        <!--
        This ID is used by the make system. Required.
        -->
        <id>bcFire</id>
        <!--
        The image source. We could set a constant called
        BC_PATH_IMAGES or something that would allow make
        to know that it should prepend that value to all
        image paths
        -->
        <src>resources/images/binarycloud/tmpl/fire.jpg</src>
        <!--
        The value of the 'name' attribute in the img tag
        -->
        <name>ImageName</name>
        <!--
        The alt attribute. Note the language reference
        -->
        <alt:en>binarycloud fire</alt:en>
        <!--
        The 'align' attribute in the img tag
        -->
        <align>left</align>
        
        <hspace>10</hspace>
        <vspace>10</vspace>
        <!--
        If left undefined, this is assumed to be 0
        -->
        <border>0</border>
        <usemap>#moo</usemap>
        <!--
        only specify these if you want to override the make system's
        automatic image-checking features
        -->
        <width>400</width>
        <height>20</height>
    </image>
</images>

Of course the other possibility is to turn this into an Entity, and run
image makes from the database... hehehe

best,

_alex




> Andi
> 
> 
> 
>> makes sense to me... seems like the best place to put "factory"
>> modules.
> 
> alex black wrote:
>> what does everyone think about having binarycloud/base/mod/ in the source
>> tree?
>> I'm thinking that we're going to have a set of modules that will be
> required
>> by certain builders and managers ( the JSRequest and CSSRequest Managers
>> come to mind)
>> 
>> thoughts?
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] binarycloud/base/mod

[Jason H. <jc...@ey...>]

AIEEEHH.. I though we were steering clear of HTML abstraction.  If the
reason to have such a Manager is to ensure all images are properly
tagged, it would make sense to abstract all/most HTML to ensure we meet
XHTML compliance.

This is so far down the line, but still an interesting thought.
jason



Alex Black wrote:
> Is anyone interested in an ImageRequestManager which would use a static
> embed tag like the module embeds:
> 
> <bc:image id="SomeImageID" />
> 
> the reason I thought of doing this:
>     -if people use this 'embed' tag, the make system can use a central image
> info repository to build well-formed tags that include alts, the _real_
> width and height of an image, etc. Of course we could allow overrides:
> 
> <bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" />
> 
> but in general you'd just use the simple tag.
> 
> I can imagine that being convenient for me... would it be convenient for
> anyone else?
> 
> The xml would probably look like:
> 
> <!-- binarycloud image repository example file -->
> <!--
> used in conjunction with:
>     <bc:image id="SomeImageID" />
> -->
> <images>
>     <image>
>         <!--
>         This ID is used by the make system. Required.
>         -->
>         <id>bcFire</id>
>         <!--
>         The image source. We could set a constant called
>         BC_PATH_IMAGES or something that would allow make
>         to know that it should prepend that value to all
>         image paths
>         -->
>         <src>resources/images/binarycloud/tmpl/fire.jpg</src>
>         <!--
>         The value of the 'name' attribute in the img tag
>         -->
>         <name>ImageName</name>
>         <!--
>         The alt attribute. Note the language reference
>         -->
>         <alt:en>binarycloud fire</alt:en>
>         <!--
>         The 'align' attribute in the img tag
>         -->
>         <align>left</align>
> 
>         <hspace>10</hspace>
>         <vspace>10</vspace>
>         <!--
>         If left undefined, this is assumed to be 0
>         -->
>         <border>0</border>
>         <usemap>#moo</usemap>
>         <!--
>         only specify these if you want to override the make system's
>         automatic image-checking features
>         -->
>         <width>400</width>
>         <height>20</height>
>     </image>
> </images>
> 
> Of course the other possibility is to turn this into an Entity, and run
> image makes from the database... hehehe

Re: [binarycloud-dev] binarycloud/base/mod

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

> AIEEEHH.. I though we were steering clear of HTML abstraction.  If the

No.
That's what formbuilder and listbuilder effectively do: abstract html so you
can just say "give me a furbees form" instead of writing a bunch of html for
every form.

> reason to have such a Manager is to ensure all images are properly
> tagged, it would make sense to abstract all/most HTML to ensure we meet
> XHTML compliance.

I disagree, though you're welcome to do that with libs, etc.

I have found that in large projects, a central ability to manage images and
their properties is useful... thus the bc:image tag thing.

Actually there wouldn't be a module or an ImageRequestManager, it would be a
function of the make system, like LangKeyer.

> This is so far down the line, but still an interesting thought.
> jason

_a

Re: [binarycloud-dev] binarycloud/base/mod

[Albert L. <a.l...@ve...>]

I use a simple clear image trick that works great when wrestling with tricky
table configurations. I like the idea of manipulating image sizes easily,
but was a little lost in your description there.

Alby

> Is anyone interested in an ImageRequestManager which would use a static
> embed tag like the module embeds:
>
> <bc:image id="SomeImageID" />
>
> the reason I thought of doing this:
>     -if people use this 'embed' tag, the make system can use a central
image
> info repository to build well-formed tags that include alts, the _real_
> width and height of an image, etc. Of course we could allow overrides:
>
> <bc:image id="SomeImageID" alt="Some Other Alt You want" width="20" />
>
> but in general you'd just use the simple tag.
>
> I can imagine that being convenient for me... would it be convenient for
> anyone else?
>
> The xml would probably look like:
>
> <!-- binarycloud image repository example file -->
> <!--
> used in conjunction with:
>     <bc:image id="SomeImageID" />
> -->
> <images>
>     <image>
>         <!--
>         This ID is used by the make system. Required.
>         -->
>         <id>bcFire</id>
>         <!--
>         The image source. We could set a constant called
>         BC_PATH_IMAGES or something that would allow make
>         to know that it should prepend that value to all
>         image paths
>         -->
>         <src>resources/images/binarycloud/tmpl/fire.jpg</src>
>         <!--
>         The value of the 'name' attribute in the img tag
>         -->
>         <name>ImageName</name>
>         <!--
>         The alt attribute. Note the language reference
>         -->
>         <alt:en>binarycloud fire</alt:en>
>         <!--
>         The 'align' attribute in the img tag
>         -->
>         <align>left</align>
>
>         <hspace>10</hspace>
>         <vspace>10</vspace>
>         <!--
>         If left undefined, this is assumed to be 0
>         -->
>         <border>0</border>
>         <usemap>#moo</usemap>
>         <!--
>         only specify these if you want to override the make system's
>         automatic image-checking features
>         -->
>         <width>400</width>
>         <height>20</height>
>     </image>
> </images>
>
> Of course the other possibility is to turn this into an Entity, and run
> image makes from the database... hehehe
>
> best,
>
> _alex
>

Re: [binarycloud-dev] binarycloud/base/mod

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

> I use a simple clear image trick that works great when wrestling with tricky
> table configurations. I like the idea of manipulating image sizes easily,
> but was a little lost in your description there.

The idea is to maintain a central 'directory' of all the images used in a
particular source tree, so you can for example modify an alt attribute in
one place and have that change propagated to _all_ the instances of that
image.

_a

RE: [binarycloud-dev] binarycloud/base/mod

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Alex,
> Is anyone interested in an ImageRequestManager which would use a
> static embed tag like the module embeds:
> <bc:image id="SomeImageID" />

that's groovy.

> I can imagine that being convenient for me...
> would it be convenient for anyone else?

Ohhh most defenetly yes.


> The xml would probably look like:

<!-- binarycloud image repository example file -->
<!--
used in conjunction with:
    <bc:image id="SomeImageID" />
-->
<images>
    <image>
        <!--
        This ID is used by the make system. Required.
        -->
        <id>bcFire</id>
        <!--
        The image source. We could set a constant called
        BC_PATH_IMAGES or something that would allow make
        to know that it should prepend that value to all
        image paths
        -->
        <src>resources/images/binarycloud/tmpl/fire.jpg</src>
        <!--
        The value of the 'name' attribute in the img tag
        -->
        <name>ImageName</name>
        <!--
        The alt attribute. Note the language reference
        -->
        <alt:en>binarycloud fire</alt:en>
        <!--
        The 'align' attribute in the img tag
        -->
        <align>left</align>

        <hspace>10</hspace>
        <vspace>10</vspace>
        <!--
        If left undefined, this is assumed to be 0
        -->
        <border>0</border>
        <usemap>#moo</usemap>
        <!--
        only specify these if you want to override the make system's
        automatic image-checking features
        -->
        <width>400</width>
        <height>20</height>
    </image>
</images>

> Of course the other possibility is to turn this into an Entity, and > run
image makes from the database... hehehe

Groovy again. That would be cool. It would also be cool to have a central
resource entity/table that holds text, imagedata, imageurls, urls etc. So we
can dynamically pull out images from database on runtime (i.e. a images
linked to a specific news article).

Nevertheless we should consider well and take care not exaggerating with
this abstraction stuff.


Andi

Re: [binarycloud-dev] binarycloud/base/mod

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

> Groovy again. That would be cool. It would also be cool to have a central
> resource entity/table that holds text, imagedata, imageurls, urls etc. So we
> can dynamically pull out images from database on runtime (i.e. a images
> linked to a specific news article).
> 
> Nevertheless we should consider well and take care not exaggerating with
> this abstraction stuff.

I agree...

though I can actually see making these "bc-tags" extensible so they are
actually module output that's just put into place at make-time instead of
render-time.

so you could just make your own tag names and assign them to modules :)

-a