Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Manuel L. <ml...@ac...> - 2001-09-22 20:00:11
|
Hello Alex, On 21-Sep-01 17:26:25, you wrote: >> Actually what I had in mind is to have a SOAP interface in the PHP Classes >> site, not in binarycloud site. That would work for any classes in there. >Cool, that would be nice. Yes, but would it work to be useful for you? >> Anyway, I think that in a few months you will want to switch from CVS to >> SubVersion and you would change only in your end. >I've been keeping tabs on SubVersion... it will be nice :) Talking about SubVersion, did you noticed Tigris.org? It looks like it could do what Sourceforge does except that it seems cleaner. If you want to host Sourceforge in a machine of yours it requires major Linux hacks and it is very hard to put it to work. Has anybody tried to host Tigris on machine of you own? Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=ml...@ac... -- E-mail: ml...@ac... URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- |
|
From: Andreas A. <a.a...@th...> - 2001-09-22 19:22:00
|
Hi Alex, >> Hmm, actually these could be the first "core" modules ... > >Precisely what I was thinking :) :) I've done this today. Integrated it in Makefiles and did a quick example in htdocs. I'll checkin tomorrow, or later tonight when i'll be back. Andi |
|
From: Alex B. <en...@tu...> - 2001-09-22 19:15:43
|
> Hi Alex,
>
> I just played around using classes as tag-compiler. Now I've worked out the
> following structure (note some renaming):
>
> - BCTagParser renamed to Bcc ("Binarycloud-Compiler")
> - compiler classes named:
> BccModuleCompiler
> BccImageCompiler
> ...
> we should consider to make a package to place the stuff in
> e.g. base/mod/bcc/
yes.
> Compiler classes follow the rules of modules. (constructor, output). Output
> must return the string that contains the compiled tag, 'false' in case of
> error (strict validation is done, so it _must_ be exactly FALSE).
>
> The tagdata that should be compiled by the Bcc*Compiler-class is passed to
> the constructor, just like $_params within modules. So the classes can also
> be used in a page context as module.
>
> Im not quite sure if we should make the Bcc object global. If so, the user
> can register the tags automatically to Bcc by just importing the compiler
> classes.
>
> i.e.
>
> -- snipp --
> <?
> class BccModuleCompiler() {
> function BccModuleCompiler($_params) {}
> function Output() {}
> }
>
> global $Bcc;
> $Bcc->RegisterTag("BC:MODULE", "BccModuleCompiler");
> ?>
> -- snipp --
>
>
> What do you think of this?
>
> Andi
Well, remember that this all happens at make-time, so I'm a _lot_ less
worried about a clean global space.
I see no reason not to make $Bcc global for convenience.
This looks fantastic, by the way :)
best,
_alex
|
|
From: Alex B. <en...@tu...> - 2001-09-22 19:13:38
|
thanks, I'll commit a fix today. _a > alex, > > error found in the new snyc version, > > base/core/Makefile - Request.php is missing in Makefile > > roni > > Ronald TAO > ron...@ho... > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-09-22 19:13:24
|
> Hi Alex, > >> what's your opinion/thoughts on using an external >> class as a handler for each bc: tag? > > I like that. It's clean and global scope is not messed up with functions. > The classes can be reused for other purposes and all > the stuff is nicely encapsulated. > > How about using the same requirements as with modules? > > Classname(): does the grunt work > Output(): returns compiled stuff to BCTagParser > > Hmm, actually these could be the first "core" modules ... Precisely what I was thinking :) _alex |
|
From: Andreas A. <a.a...@th...> - 2001-09-22 14:10:52
|
> Im not quite sure if we should make the Bcc object global.
> If so, the user can register the tags automatically to
> Bcc by just importing the compiler >classes.
I retire that. It's bad to do so, this might lead to conflicts if the user
wants to use a compiler module outside bcc context.
Better is to use something like this:
--- base/mod/bcc/BccInit.php ---
import('binarycloud.mod.bcc.Bcc');
import('binarycloud.mod.bcc.BccModuleCompiler');
import('binarycloud.mod.bcc.BccImgCompiler');
global $Bcc;
$Bcc = new Bcc();
$Bcc->knownTags(
'BC:MODULE' => "BccModuleCompiler",
'BC:IMG' => "BccImgCompiler"
);
---/ base/mod/bcc/BccInit.php ---
|
|
From: Andreas A. <a.a...@th...> - 2001-09-22 13:32:18
|
Hi Alex,
I just played around using classes as tag-compiler. Now I've worked out the
following structure (note some renaming):
- BCTagParser renamed to Bcc ("Binarycloud-Compiler")
- compiler classes named:
BccModuleCompiler
BccImageCompiler
...
we should consider to make a package to place the stuff in
e.g. base/mod/bcc/
Compiler classes follow the rules of modules. (constructor, output). Output
must return the string that contains the compiled tag, 'false' in case of
error (strict validation is done, so it _must_ be exactly FALSE).
The tagdata that should be compiled by the Bcc*Compiler-class is passed to
the constructor, just like $_params within modules. So the classes can also
be used in a page context as module.
Im not quite sure if we should make the Bcc object global. If so, the user
can register the tags automatically to Bcc by just importing the compiler
classes.
i.e.
-- snipp --
<?
class BccModuleCompiler() {
function BccModuleCompiler($_params) {}
function Output() {}
}
global $Bcc;
$Bcc->RegisterTag("BC:MODULE", "BccModuleCompiler");
?>
-- snipp --
What do you think of this?
Andi
|
|
From: Ronald T. <ron...@ho...> - 2001-09-22 04:08:09
|
alex, error found in the new snyc version, base/core/Makefile - Request.php is missing in Makefile roni Ronald TAO ron...@ho... _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp |
|
From: Andreas A. <a.a...@th...> - 2001-09-22 01:23:12
|
Hi Alex, > what's your opinion/thoughts on using an external > class as a handler for each bc: tag? I like that. It's clean and global scope is not messed up with functions. The classes can be reused for other purposes and all the stuff is nicely encapsulated. How about using the same requirements as with modules? Classname(): does the grunt work Output(): returns compiled stuff to BCTagParser Hmm, actually these could be the first "core" modules ... > Also, Charlie: what work have you done with the > Langkeyer? hopefully you've been working on the > directory-lookup class, so we'll just be able to > plug that in to the BCTagParser as a handler for > bc:string :) cool!!! Andi |
|
From: Alex B. <en...@tu...> - 2001-09-21 23:29:37
|
hi all, what does everyone think about being able to create 'handler classes' for custom tags which will be interpreted by the system at make-time? I'm thinking of people who will want to create strange variants of the lang keyer, or add some other special set of logic that would be convenient to store in a tag. Andi, what's your opinion/thoughts on using an external class as a handler for each bc: tag? Also, Charlie: what work have you done with the Langkeyer? hopefully you've been working on the directory-lookup class, so we'll just be able to plug that in to the BCTagParser as a handler for bc:string :) best, _alex |
|
From: Alex B. <en...@tu...> - 2001-09-21 23:26:14
|
hi all, code is synced to public cvs, please do an update. best, _alex |
|
From: Alex B. <en...@tu...> - 2001-09-21 20:26:02
|
> Actually what I had in mind is to have a SOAP interface in the PHP Classes > site, not in binarycloud site. That would work for any classes in there. Cool, that would be nice. > Anyway, I think that in a few months you will want to switch from CVS to > SubVersion and you would change only in your end. I've been keeping tabs on SubVersion... it will be nice :) _a |
|
From: Alex B. <en...@tu...> - 2001-09-21 20:25:24
|
cool!
)a
> Hi Alex, all,
>
> just checked in a revision of BCTagParser. What works:
>
> - register tags and the compiler method:
> ie.e RegisterTag('BC:JS', 'BCCompileTagJs');
> - looking for <bc:*>..</bc:*> and <bc:* /> style tags
> - calling the registered methods that compile the tags
> - take compiler-output and replace original tags with it
>
> <bc:module> should work instantly if XMLUtils would handle this. Maybe
> Andris can extend it!?
>
> To test the whole thing I attached the file I used for testing. Just place
> it in base/lib/ (dirty way) and call:
>
> php BCTagParser.php
>
> The resulting file data.html will (hopefully) contain the compiled stuff.
>
> I'll clear up all this so that the class file is not executing the parser.
> This might go to xml2php or a extra file bctag2php or someting similar
> suitable for make.
>
> Andi
>
>
>
>
|
|
From: Andreas A. <a.a...@th...> - 2001-09-21 16:06:30
|
Hi Alex, all,
just checked in a revision of BCTagParser. What works:
- register tags and the compiler method:
ie.e RegisterTag('BC:JS', 'BCCompileTagJs');
- looking for <bc:*>..</bc:*> and <bc:* /> style tags
- calling the registered methods that compile the tags
- take compiler-output and replace original tags with it
<bc:module> should work instantly if XMLUtils would handle this. Maybe
Andris can extend it!?
To test the whole thing I attached the file I used for testing. Just place
it in base/lib/ (dirty way) and call:
php BCTagParser.php
The resulting file data.html will (hopefully) contain the compiled stuff.
I'll clear up all this so that the class file is not executing the parser.
This might go to xml2php or a extra file bctag2php or someting similar
suitable for make.
Andi
|
|
From: Manuel L. <man...@uo...> - 2001-09-21 12:22:07
|
Hello, >> It seems that you so much manual work to syncronize, that I was wondering if I >> could make it easier for you. So, I wonder if there would be a way to let you >> do it, by for instance providing a SOAP interface to let you request files or >> packages in a programatic way. Would that help? Would it be useful? > >hi Manuel, > >that was certainly in the plans for the future... if you have or would like >to construct some way of doing that, I'd be ecstatic. > >so yes, that would be _extremely_ useful :) > >Most of the thought I had put into that was related to modules, the idea >being that you download and install the binarycloud base tarball, and would >then use the distro system to install modules. > >But we could expand that capability to everything, so you only download the >"installer" and get all the core and modules you need at once. > >The 'syncing' I do is because I wanted to keep an internal 'core' >binarycloud repository separate from the public sourceforge r2 repository. > >I have to sync cvs "manually" but it isn't that hard, I have a script which >does most of the analysis for me, and commits the deltas when I want. Actually what I had in mind is to have a SOAP interface in the PHP Classes site, not in binarycloud site. That would work for any classes in there. Anyway, I think that in a few months you will want to switch from CVS to SubVersion and you would change only in your end. Regards, Manuel Lemos |
|
From: Alex B. <en...@tu...> - 2001-09-20 22:39:44
|
great. I'll commit and sync later today. _a > Hi Alex, > > that are exactly the changes I commited back to manuel plus some other > stuff. So, yes, you can update cvs with the new metabase. > > Tomorrow I'll remove the metabase hack and abstraction code from > QueryManager and use of the official new methods. > > Andi > > >> andi: >> >> manuel has just uploaded a major metabase update to phpclasses... >> are those patches in CVS? >> >> I don't want to commit over any changes you've made >> (though I think these >> new files will probably solve a lot of our problems. > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Andreas A. <a.a...@th...> - 2001-09-20 22:02:43
|
Hi Alex, that are exactly the changes I commited back to manuel plus some other stuff. So, yes, you can update cvs with the new metabase. Tomorrow I'll remove the metabase hack and abstraction code from QueryManager and use of the official new methods. Andi >andi: > > manuel has just uploaded a major metabase update to phpclasses... > are those patches in CVS? > > I don't want to commit over any changes you've made > (though I think these > new files will probably solve a lot of our problems. |
|
From: Alex B. <en...@tu...> - 2001-09-20 17:59:18
|
andi: manuel has just uploaded a major metabase update to phpclasses... are those patches in CVS? I don't want to commit over any changes you've made (though I think these new files will probably solve a lot of our problems. best, _alex |
|
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: 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-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 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-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: 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 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 |
5 messages has been excluded from this view by a project administrator.
