binarycloud-dev — development list for binarycloud

Re: [binarycloud-dev] BCTagParser.php

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

not at all,
and that's precisely what I'm pointing to...

in theory I like the idea of forcing xhtml, in practice I don't want to do
it because of the production implications.

I think we're better off allowing users to do what they please.

_a

> I agree, in that it makes sense to stick with XML/XHTML formatting for
> everything.  The advantages here are obvious.  If this is the chosen
> path, I would not have a problem with this either.
> 
> Though, as I think most people would agree, it should be up to the user.
> 
> If ALL HTML was generated by BinaryCloud through some tag conversion,
> I'd be more inclined to say that the user should have a choice of
> HTML3.2, HTML4.1, or XHTML1.0, but this isn't what the tag parser really
> does.
> 
> If a master template uses loose HTML3.2, and the BCP output is strict
> XHTML, the resulting page would still not meet XHTML qualification.
> Because it is up to the user how he writes his HTML templates, it should
> also be up to the user how he writes his BCP pages.
> 
> I hope I'm not missing the overall picture with my point.
> jason
> 
> 
> 
> "Andreas Aderhold (Thyrell)" wrote:
>> I think if we start using xml stuff (we already have in the configs) we
>> should use it throughout the system. Ok, it would force xhtml on users - but
>> bc is targeting professional users and big projects. So using xhmtl would
>> not be a drawback in my mind.
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] BCTagParser.php

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

> Hi Alex,
> 
> Hmm regex is another option. This could be a part of the the
> TemplateManager. So we can do stuff like <bc:tmpl var="something" /> that
> would make into <?=$TemplateManager->handle["something"]?> or something
> similar.

That's a possibility, but I think in most cases the <bc: tags will be
interpreted into either static html, or (in the case of the <bc:module> tag,
a call to Page)

> How are your plans for the native TemplateManager. Will it be a xslt thing
> (as planed some months ago) or will it be more like smarty (replace) or
> completely make based with bc:style tags ?

Any and all of that:
    TemplateManager will be a simple generalized set of methods for applying
templates to data using xslt, smarty, native php, whatever people want.

I view the <bc:> tags more as a function of the make system than a runtime
thing.

> I'm still unsure about the xhtml/xml/xslt stuff. It would simple things up
> and also make the docs clear and usable by transformers.

I agree, though I see some problems with doing that - there really aren't
that many good xslt tools out there and people won't necessarily want to use
it.

Also, I'd like the flexibility to use xslt if I want, or just be lazy and
use native php. :)

> I know if we use that it's enforcing policy. But in the process of
> standardizing things it's a logical step. And for what are standards? They
> force something so that everybody that knows the standard can use it ;-)

I agree, but I would prefer to use standards that come from wc3, not create
my own production standards. I have a certain way of doing things: some
people like that way and others I'm sure do not.

I would far prefer that binarycloud be flexible enough for people to
configure it and use it to suit their particular needs.

> I mean, using standardized technology will make live easier, even if people
> are not used to close the <img> tag. In my opinion it's not a big deal to
> close them. To learn this it's a matter of an hour or so. The loose-xhtml
> standard is not much different from html.

That's true. So we really may want to consider it. But I can see other
problems with it:

    -what do you do with embedded "native" php in templates that is parsed
as a processing instruction?
    -we would be forced to build _some_ kind of debugging support during
make that would point syntax errors during make, or I can see peole going
crazy trying to find problems.

etc.

> I think if we start using xml stuff (we already have in the configs) we
> should use it throughout the system. Ok, it would force xhtml on users - but
> bc is targeting professional users and big projects. So using xhmtl would
> not be a drawback in my mind.

I agree, but with the caveats above.

I think for the moment that regex is preferable because the tag syntax isn't
complex. also, you can rely on the fact that the tags are valid xml within
their own scope, so you could pass them to a parser in little chunks and get
arrays back :)


_a

> 
> Andi
> 
> 
>> Or, because of the simplicity of the tags, we could probably
>> build a regex that would get 'em all.
>> 
>> _a
>> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] BCTagParser.php

[Charlie K. <Ch...@Al...>]

Where does the BCString Keyer fit into this?
It seems to me if we are regexing through all the pages at build time this
process should include keying in text strings for multi-language capability
at this point.

Example from Alex:
<lang>strings.xml.hello</lang>

xml file:
<strings>
 <string>
  <id>hello</id>
  <lang:en>Hello</lang:en>
  <lang:fr>Bonjour</lang:fr>
  <description>This string is used on the home page in "hello,
$username".</description>
 </string>
</strings>

Charlie

Re: [binarycloud-dev] BCTagParser.php

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

I agree, in that it makes sense to stick with XML/XHTML formatting for
everything.  The advantages here are obvious.  If this is the chosen
path, I would not have a problem with this either.

Though, as I think most people would agree, it should be up to the user.

If ALL HTML was generated by BinaryCloud through some tag conversion,
I'd be more inclined to say that the user should have a choice of
HTML3.2, HTML4.1, or XHTML1.0, but this isn't what the tag parser really
does.

If a master template uses loose HTML3.2, and the BCP output is strict
XHTML, the resulting page would still not meet XHTML qualification. 
Because it is up to the user how he writes his HTML templates, it should
also be up to the user how he writes his BCP pages.

I hope I'm not missing the overall picture with my point. 
jason



"Andreas Aderhold (Thyrell)" wrote:
> I think if we start using xml stuff (we already have in the configs) we
> should use it throughout the system. Ok, it would force xhtml on users - but
> bc is targeting professional users and big projects. So using xhmtl would
> not be a drawback in my mind.

RE: [binarycloud-dev] BCTagParser.php

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

Hi Alex,

Hmm regex is another option. This could be a part of the the
TemplateManager. So we can do stuff like <bc:tmpl var="something" /> that
would make into <?=$TemplateManager->handle["something"]?> or something
similar.

How are your plans for the native TemplateManager. Will it be a xslt thing
(as planed some months ago) or will it be more like smarty (replace) or
completely make based with bc:style tags ?

I'm still unsure about the xhtml/xml/xslt stuff. It would simple things up
and also make the docs clear and usable by transformers.

I know if we use that it's enforcing policy. But in the process of
standardizing things it's a logical step. And for what are standards? They
force something so that everybody that knows the standard can use it ;-)

I mean, using standardized technology will make live easier, even if people
are not used to close the <img> tag. In my opinion it's not a big deal to
close them. To learn this it's a matter of an hour or so. The loose-xhtml
standard is not much different from html.

I think if we start using xml stuff (we already have in the configs) we
should use it throughout the system. Ok, it would force xhtml on users - but
bc is targeting professional users and big projects. So using xhmtl would
not be a drawback in my mind.


Andi


> Or, because of the simplicity of the tags, we could probably
> build a regex that would get 'em all.
>
>_a
>

Re: [binarycloud-dev] BCTagParser.php

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

Or, because of the simplicity of the tags, we could probably build a regex
that would get 'em all.

_a

> Hi Alex,
> 
>> Interesting that the way you're doing this (parsing xml)
>> would enforce the use of xhtml throughout the system...
> Yes, the xml_parser* stuff requires this.
> 
>> which I'm not sure people are comfortable with yet.
>> Of course it makes your html nice and clean, but I can
>> see that possibly screwing some people up.
>> Opinions on this?
> I like it, but we should not enforce this on users.
> 
>> For _my_ projects this is fine, but I want to check with everyone
>> else :)
> 
> For me it's also fine. But this should not be a must in the source files.
> Maybe this can be swichted off somehow with expat, (I'll have a look). If
> not we could provide a util that converts all html to xhtml during make
> (maybe something already exists out there)
> 
> Andi
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

RE: [binarycloud-dev] additional methods within modules

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

Hi Alex,

Ah, cool. I thought it's a kind of policy that only the two methods exist.
Groovy.

Andi


>> goes it bc conform to add private methods to modules?
>> So the module consists of ModuleName(), Output() and
>> some other _MethodThatDoesSomething()
>
> Absolutely.
>
> You may have other public methods, also.
>
> The only requirement is that if you want to use the module with
> Page, it has to have a constructor and the method Output().

RE: [binarycloud-dev] BCTagParser.php

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

Hi Alex,

>This is great code, btw... have you checked it in?
Thanks, but it's very early and I just played around with it. I'll check in
now.

Andi

RE: [binarycloud-dev] BCTagParser.php

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

Hi Alex,

> Interesting that the way you're doing this (parsing xml)
> would enforce the use of xhtml throughout the system...
Yes, the xml_parser* stuff requires this.

> which I'm not sure people are comfortable with yet.
> Of course it makes your html nice and clean, but I can
> see that possibly screwing some people up.
> Opinions on this?
I like it, but we should not enforce this on users.

> For _my_ projects this is fine, but I want to check with everyone
> else :)

For me it's also fine. But this should not be a must in the source files.
Maybe this can be swichted off somehow with expat, (I'll have a look). If
not we could provide a util that converts all html to xhtml during make
(maybe something already exists out there)

Andi

Re: [binarycloud-dev] anonymous cvs

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

what peter said: sounds like you have a dns problem

_a

> Hello,
> 
> I was told some time ago to get a cvs copy of version 2 to test
> and begin to understand...
> Maybe am I stupid but I cannot succed into connecting to cvs :
> if I type
> cvs
> -d:pserver:ano...@cv...:/cvsroot/binarycloud
> login
> I am told 'Unknown host'.
> Did I miss something ?
> 
> Thanks
> PS: I am on Linux, I know about Linux, shell, php, mysql but not much
> about cvs.
> 
> JCM
> --
> web...@fo...
> +----------------------------------------------------------------+
> | http://www.symetrie.com/    Edition de musique/Music publisher |
> | http://www.foliomusic.com/     Librairie musicale/Scores store |
> +----------------------------------------------------------------+
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] BCTagParser.php

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

This is great code, btw... have you checked it in?

-a

> Hi All,
> 
> just started an early shell of what might become a tool to help get the
> <bc:something> stuff working. It's a simple class called BCTagParser. It
> processes a file and it's looking for <bc:tag> then starting up methods that
> process this tags (=> conversion to php).
> 
> You can register each tag and the relating processing method. So it will
> become easy to register custom tags.
> 
> This is a _very_ early shell and maybe this approach isn't the right or best
> one. I'd love to hear your opinions.
> 
> 
> Andi
> 
> 
> << see attached files >>
> 

Re: [binarycloud-dev] BCTagParser.php

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

> Hi All,
> 
> just started an early shell of what might become a tool to help get the
> <bc:something> stuff working. It's a simple class called BCTagParser. It
> processes a file and it's looking for <bc:tag> then starting up methods that
> process this tags (=> conversion to php).
> 
> You can register each tag and the relating processing method. So it will
> become easy to register custom tags.
> 
> This is a _very_ early shell and maybe this approach isn't the right or best
> one. I'd love to hear your opinions.
> 
> 
> Andi
> 
> 
> << see attached files >>
> 



Interesting that the way you're doing this (parsing xml) would enforce the
use of xhtml throughout the system... which I'm not sure people are
comfortable with yet. Of course it makes your html nice and clean, but I can
see that possibly screwing some people up.

Opinions on this?

For _my_ projects this is fine, but I want to check with everyone else :)

_a

Re: [binarycloud-dev] additional methods within modules

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

> Hi Alex,
> 
> goes it bc conform to add private methods to modules? So the module consists
> of ModuleName(), Output() and some other _MethodThatDoesSomething()

Absolutely.

You may have other public methods, also.

The only requirement is that if you want to use the module with Page, it has
to have a constructor and the method Output().

_a

> Andi

Re: [binarycloud-dev] Handling of resources/ in htdocs

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

agreed, though all those mappings can be done with virtualhosts (aliases)
and/or just copying the files over...

so I think we implicitly support those right now.

-a

> Hey Alex,
> 
>>> Currently i run a symlink to the language builds htdocs
>>> dir within the vhost dir. So in  www.foo.com/en/
>>> the "en" is a symlink to build/en/htdocs.
> 
>> That's exactly how I do it, and I think that works
>> well... can you think of
>> any other ways people might want to do it?
> 
> I prefer that too. But maybe someone wants to use subdomains.
> 
> http://en.foo.com/
> http://da.foo.com/
> 
> or the toplevel variant:
> 
> http://www.foo.com -> english
> http://www.foo.da -> dansk
> http://www.foo.de -> german
> 
> I think we should support all theese variants. At least from the
> "commercial-usage" point of view. (You know: they insist of having a
> subdomain per language and nobody or nothing can change their mind)
> 
> 
> Andi
> 
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] anonymous cvs

[peter m. <pm...@sp...>]

oops, meant to be a private reply.  ah well.  btw, the following is wrong, i
don't have a server there anymore.  sorry.

Peter

On Sun, Sep 16, 2001 at 01:51:02PM -0500, peter mcarthur wrote:
> 
> if yours is down, you can use mine for the time being, but no guarantees on
> future reliability.  my /etc/resolv.conf looks like this:
> 
> nameserver 64.39.14.39
> 

Re: [binarycloud-dev] anonymous cvs

[peter m. <pm...@sp...>]

what do you get when you type

host cvs.binarycloud.sourceforge.net

and,

host www.ibm.com

this is assuming you have bind-utils installed.
anyway, that host resolves for me, so i would check your /etc/resolv.conf,
and just make sure you have a nameserver that resolves hostnames....

if yours is down, you can use mine for the time being, but no guarantees on
future reliability.  my /etc/resolv.conf looks like this:

nameserver 64.39.14.39

i'd highly recommend installing a local dns cache, if you have control of
the machine.  check out http://cr.yp.to/djbdns.html, there is some cool
stuff there.


On Sun, Sep 16, 2001 at 07:32:53PM +0200, JCM wrote:
> Hello,
> 
> I was told some time ago to get a cvs copy of version 2 to test
> and begin to understand...
> Maybe am I stupid but I cannot succed into connecting to cvs :
> if I type
> cvs
> -d:pserver:ano...@cv...:/cvsroot/binarycloud
> login
> I am told 'Unknown host'.
> Did I miss something ?
> 
> Thanks
> PS: I am on Linux, I know about Linux, shell, php, mysql but not much
> about cvs.
> 
> JCM
> --
> web...@fo...
> +----------------------------------------------------------------+
> | http://www.symetrie.com/    Edition de musique/Music publisher |
> | http://www.foliomusic.com/     Librairie musicale/Scores store |
> +----------------------------------------------------------------+
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev

[binarycloud-dev] anonymous cvs

[JCM <sym...@on...>]

Hello,

I was told some time ago to get a cvs copy of version 2 to test
and begin to understand...
Maybe am I stupid but I cannot succed into connecting to cvs :
if I type
cvs
-d:pserver:ano...@cv...:/cvsroot/binarycloud
login
I am told 'Unknown host'.
Did I miss something ?

Thanks
PS: I am on Linux, I know about Linux, shell, php, mysql but not much
about cvs.

JCM
--
web...@fo...
+----------------------------------------------------------------+
| http://www.symetrie.com/    Edition de musique/Music publisher |
| http://www.foliomusic.com/     Librairie musicale/Scores store |
+----------------------------------------------------------------+

[binarycloud-dev] BCTagParser.php

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

Hi All,

just started an early shell of what might become a tool to help get the
<bc:something> stuff working. It's a simple class called BCTagParser. It
processes a file and it's looking for <bc:tag> then starting up methods that
process this tags (=> conversion to php).

You can register each tag and the relating processing method. So it will
become easy to register custom tags.

This is a _very_ early shell and maybe this approach isn't the right or best
one. I'd love to hear your opinions.


Andi


<< see attached files >>

[binarycloud-dev] additional methods within modules

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

Hi Alex,

goes it bc conform to add private methods to modules? So the module consists
of ModuleName(), Output() and some other _MethodThatDoesSomething()

Andi

RE: [binarycloud-dev] Handling of resources/ in htdocs

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

Hey Alex,

>> Currently i run a symlink to the language builds htdocs
>> dir within the vhost dir. So in  www.foo.com/en/
>> the "en" is a symlink to build/en/htdocs.

> That's exactly how I do it, and I think that works
> well... can you think of
> any other ways people might want to do it?

I prefer that too. But maybe someone wants to use subdomains.

http://en.foo.com/
http://da.foo.com/

or the toplevel variant:

http://www.foo.com -> english
http://www.foo.da -> dansk
http://www.foo.de -> german

I think we should support all theese variants. At least from the
"commercial-usage" point of view. (You know: they insist of having a
subdomain per language and nobody or nothing can change their mind)


Andi

Re: [binarycloud-dev] Handling of resources/ in htdocs

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

----- Original Message -----
From: "Andreas Aderhold (Thyrell)" <a.a...@th...>
To: <bin...@li...>
Sent: Saturday, September 15, 2001 6:45 AM
Subject: RE: [binarycloud-dev] Handling of resources/ in htdocs


> Hi Alex,
>
> > Yes, the way to solve this is during the make process in combination >
> with a path constant:
> > BC_PATH_RESOURCES
> > so all of your paths _will_ be absolute, but based on a variable :)
>
> Very cool. Another question. Is the build tree layout final or will it
> change? I mean the language stuff is going to different subdirs:
>
> build/en/htdocs ...
> build/de/htdocs ...
>
> Currently i run a symlink to the language builds htdocs dir withing the
> vhost dir. So in  www.foo.com/en/ the "en" is a symlinkg to
build/en/htdocs.

That's exactly how I do it, and I think that works well... can you think of
any other ways people might want to do it?

_a

RE: [binarycloud-dev] Handling of resources/ in htdocs

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

Hi Alex,

> <bc:img id="abcimg" />
> <bc:js id="moo" inline="true" />
> <bc:css id="moo" inline="false" />
> <bc:href id="href" href="/archive/mp3/any_document.mp3" 
> usedocroot="true" |
> usersrcroot="true" /> (or something)

usedocroot is fine.


> which will be 'made' into:
> <img src="/value/of/rsrc/constant/a/b/c/image.jpg" border="0" 
> width="12" height="123">
Groovy.


> I very much want to avoid the use of "constant echos" that are 
> unnecessary at runtime: if you already have implicit 
> knowledge about your environment, there's no reason to 
> repeat the same logic over and over.

Agreed.


> What are people's opinions on these 'tags' ?

I like this. Let's do it.



Andi

RE: [binarycloud-dev] Handling of resources/ in htdocs

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

Hi Alex,

> Yes, the way to solve this is during the make process in combination >
with a path constant:
> BC_PATH_RESOURCES
> so all of your paths _will_ be absolute, but based on a variable :)

Very cool. Another question. Is the build tree layout final or will it
change? I mean the language stuff is going to different subdirs:

build/en/htdocs ...
build/de/htdocs ...

Currently i run a symlink to the language builds htdocs dir withing the
vhost dir. So in  www.foo.com/en/ the "en" is a symlinkg to build/en/htdocs.



Andi

Re: [binarycloud-dev] Handling of resources/ in htdocs

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

> 
> To clear any cloudy air, so accessing ANYTHING in resources/ will be a
> combination of a constant and an absolute path, correct?
> 
> TMPL EG:
> <script src="<?=RESOURCE_CONSTANT?>/what/ever/script.js">
> 
> <img src="<?=RESOURCE_CONSTANT?>/a/b/c/image.jpg">
> 
> <a href="<?=RESOURCE_CONSTANT?>/archive/mp3/any_document.mp3">click to
> download this MP3</a>
> 
> 
> Or is this to simplified?

More like:

<bc:img id="abcimg" />
<bc:js id="moo" inline="true" />
<bc:css id="moo" inline="false" />
<bc:href id="href" href="/archive/mp3/any_document.mp3" usedocroot="true" |
usersrcroot="true" /> (or something)

which will be 'made' into:

<img src="/value/of/rsrc/constant/a/b/c/image.jpg" border="0" width="12"
height="123">

<script language="JavaScript">
function Moo() {
    return;
}
</script>


<link rel="stylesheet" href="/value/of/rsrc/constant/css/moo.css" />

<a href="/value/of/rsrc/constant/archive/mp3/any_document.mp3">Click to
Download MP3</a>

I very much want to avoid the use of "constant echos" that are unnecessary
at runtime: if you already have implicit knowledge about your environment,
there's no reason to repeat the same logic over and over.

What are people's opinions on these 'tags' ?

best,

_alex



> jason
> 
> Alex Black wrote:
>>> I too have wondered this.  I'd vote highly against the use of any
>>> absolute paths unless they are preceed by a definable constant.
>> 
>> Which is exactly what ImageRequestManager will do.
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] Handling of resources/ in htdocs

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

To clear any cloudy air, so accessing ANYTHING in resources/ will be a
combination of a constant and an absolute path, correct? 

TMPL EG:
<script src="<?=RESOURCE_CONSTANT?>/what/ever/script.js">

<img src="<?=RESOURCE_CONSTANT?>/a/b/c/image.jpg">

<a href="<?=RESOURCE_CONSTANT?>/archive/mp3/any_document.mp3">click to
download this MP3</a>


Or is this to simplified?

jason

Alex Black wrote:
> > I too have wondered this.  I'd vote highly against the use of any
> > absolute paths unless they are preceed by a definable constant.
> 
> Which is exactly what ImageRequestManager will do.