Menu
▾
▴
binarycloud-dev
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-16 13:10:45
Attachments:
BCTagParser.php
data.html.xml
|
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 >> |
|
From: Alex B. <en...@tu...> - 2001-09-16 20:25:14
|
> 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 |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-16 20:35:45
|
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 |
|
From: Alex B. <en...@tu...> - 2001-09-16 21:05:39
|
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 > |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-18 09:07:13
|
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 > |
|
From: Jason H. <jc...@ey...> - 2001-09-18 14:48:46
|
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. |
|
From: Alex B. <en...@tu...> - 2001-09-18 20:35:56
|
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 > |
|
From: Andreas A. <a.a...@th...> - 2001-09-18 21:48:09
|
Hi Alex, Jason, > 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. Ok, you convinced me :-) Andi |
|
From: Alex B. <en...@tu...> - 2001-09-18 21:59:10
|
hehe :) > Hi Alex, Jason, > >> 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. > > Ok, you convinced me :-) > > Andi > > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-09-18 20:34:21
|
> 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
>
|
|
From: Andreas A. <a.a...@th...> - 2001-09-18 21:48:09
|
Hey 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) Ok, I don't want the <bc:*> tags parsed at runtime. > TemplateManager will be a simple generalized set of methods > for applying templates to data using xslt, smarty, native > php, whatever people want. Got it. Cool. > I view the <bc:> tags more as a function of the make > system than a runtime thing. 100% agree. Transforming them at run-time would be lame. I never ever thought of that. I thought of bc:tag that makes into a php echo ing something. That was 'caus I misunderstood template manager as the actual template engine. > Also, I'd like the flexibility to use xslt if I want, > or just be lazy and use native php. :) I see the point. >> 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. Uh, don't misunderstand. With "standard" I tought of official standards like the w3c recommendations not something own. > 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. Agreed. [xhtml] > 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? That's a problem, alright. > -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. good point. > 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 :) Hmm, ok I see It's better for now I guess. The additional overhead (debug, embedding native php) and the somehow limited flexiblity does not sacrifice using this standards (now) that may become "common" in some years. Andi |
|
From: Alex B. <en...@tu...> - 2001-09-18 21:58:54
|
>> I agree, but I would prefer to use standards that come from >> wc3, not create my own production standards. > Uh, don't misunderstand. With "standard" I tought of official standards like > the w3c recommendations not something own. oh, cool :) > Hmm, ok I see It's better for now I guess. The additional overhead (debug, > embedding native php) and the somehow limited flexiblity does not sacrifice > using this standards (now) that may become "common" in some years. yeah, i think we can probably make it happen without forcing xhtml.. -a |
|
From: Andreas A. <a.a...@th...> - 2001-09-19 08:07:01
|
Hi Alex, > yeah, i think we can probably make it happen without forcing xhtml.. So, now I have the following picture of BCTagParser in my mind- correct me if you disagree: - parse a textfile with a regex - if <bc:*> occurs read the hole tag into a buffer - pass this buffer to the xml parser that processes the buffer - the xml parser calls the tag-handling-method (if it is registered, otherwise ignores) and returns a string (i.e. generated php) - the <bc:*> tag is replaced with the generated php in the target-file-buffer - regex goes to next occuring tag and repeats the above - EOF => resulting file is written Andi |
|
From: Alex B. <en...@tu...> - 2001-09-19 20:36:33
|
> Hi Alex, > >> yeah, i think we can probably make it happen without forcing xhtml.. > > So, now I have the following picture of BCTagParser in my mind- correct me > if you disagree: > > - parse a textfile with a regex > - if <bc:*> occurs read the hole tag into a buffer > - pass this buffer to the xml parser that processes > the buffer > - the xml parser calls the tag-handling-method (if it is > registered, otherwise ignores) and returns a string > (i.e. generated php) This is al correct, but note that in this case the returned string may be just a string. That's because we'll use the bc:tag method to key in strings to code and markup. > - the <bc:*> tag is replaced with the generated php > in the target-file-buffer > - regex goes to next occuring tag and repeats the above > - EOF => resulting file is written Let's test the speed of a system like that within make... if it's nasty we can run a precaching step that builds a list of files that need to be processed. best, _alex |
|
From: Charlie K. <Ch...@Al...> - 2001-09-18 19:11:05
|
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 |
|
From: Alex B. <en...@tu...> - 2001-09-18 20:38:34
|
I think it will end up being onf of the system 'tags': <bc:string id="moo.boo" /> The keyer is relatively simple (it has to be a regex) because (while we are using xml syntax) the 'tags' aren't always in a valid xml context. > 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 best, _alex |
|
From: Alex B. <en...@tu...> - 2001-09-16 20:25:27
|
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 >> > |
|
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-16 20:37:07
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X