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: Alex B. <en...@tu...> - 2001-07-26 23:16:39
|
hi all, I have decided to axe my current binarycloud.com host machine which has cvs, etc etc on it. Starting now, bc will be using sourceforge cvs 100%: all of my internal development will be synched to sourceforge on a daily basis. Eventually, if there is enough "external" activity to warrant the change, I will not run internal dev cvs for r2, and sourceforge will become the master repository... If we decide to set up a review process, sf may remain the "public free for all cvs" while my internal cvs will be the "release version" If you would like commit access to the binarycloud r2 repository, you will need to send me your sourceforge username: if you don't have one get it at http://sourceforge.net/account/register.php Please send your request to binarycloud-dev, with the subject "sf-cvs access" so I can make sure I get everyone on. I'm going to send a detailed email with all the instructions, etc you'll need to get set up with sourceforge cvs... Also, note that for core developers I'm going to offer email addresses @binarycloud.com :) --------- :) _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-26 22:04:48
|
> I would like a facility in BC that allowed multiple layouts
> per group. The reason for this is the felt need to have
> some "standard" layouts that are quite common. Just to
> give an example, there may be a site that in the "main pane"
> (not the master template scope) there is a need for a
> standard piece of HTML decoration, text or whatever, such
> as maybe a copyright notice, a set of links, a mailto: to
> the webmaster or whatever.
>
> Logically, something like the below would be necessary,
> namely you need anoth'layout' => array(
> 'one' => array(
> 'name' => "example",
> 'package' => "html.layouts",
> ),
> 'two' => array(
> 'name' => "copyright",
> 'package' => "html.layouts",
> ),
> 'three' => array(
> 'name' => "webmaster",
> 'package' => "html.layouts",
> ),
> ),
ola:
well, you're going to have the ability to have modules directly embedded in
master templates.
layouts are really intended to "catch" those extra bits of html that you
don't necessarily want to include in a module (say a paragraph break between
modules, or a specific table layout, etc)
The "default modules" thing is something I'm working on right after the PEAR
integration, actually.
I was thinking of this syntax, actually:
<html>
<p> Other crap in a template </p>
<bc:module id="moo" name="HelloWorld" package="hello_world">
<params>
<attribute>value</attribute>
<attribute>value</attribute>
<attribute>value</attribute>
<attribute>value</attribute>
</params>
</bc:module>
</html>
gets translated into:
<?php $Page->OutputModule(array('id' => 'moo','name' =>
'HelloWorld','package' => 'hello_world','params' => array('attribute' =>
'value','attribute' => 'value','attribute' => 'value','attribute' =>
'value'))); ?>
at make time.
Note that the <?$Page->OutputModule(stuff)?> syntax will work in _any_
template, so theoretically you could have a module that includes a template
that outputs another module and some extra stuff. The possibilities are of
course infinite, system design is up to the user.
Also note that $Page->OutputModule doesn't exist yet and I may change the
name :)
I would prefer to use xslt for the above translation, but that would require
that all templates are valid xml documents, which could be a real pain in
the a** to support (single root elements not least among those problems). It
will probably be just a boring grep, as I really don't want to lock people
into using xhtml for _everything_.
> er array level, viz:
>
> 'layout' => array(
> 'one' => array(
> 'name' => "example",
> 'package' => "html.layouts",
> ),
> 'two' => array(
> 'name' => "copyright",
> 'package' => "html.layouts",
> ),
> 'three' => array(
> 'name' => "webmaster",
> 'package' => "html.layouts",
> ),
> ),
>
> and the example layout may have the buffer output, but
> the "copyright" and "webmaster" layouts are just
> very common bits of HTML and have no Output()
> stuff at all....
I'm not really opposed in theory to doing that, but at the same time I
_love_ that the page class is so clean and simple. As much as I can preserve
clarity and simplicity in that class, I'd like to.
The system as it stands is quite flexible, I think you'll be able to do that
stuff without a problem as soon as I get "embedded" module support up for
layouts and master templates. (and for that matter, anywhere)
> Right now, if you have standard header_like_things and
> footer_like_things in various groups, you must make a
> single layout for that group with all the bits and pieces
> necessary, even though these bits and pieces make up
> a set.
Yes, that's kludegeware, default modules will solve all those problems.
> Anyway, I won't try and justify this. I feel this need,
> and I suppose that I would like for the rest of the group
> to comment on it.
I see it as well, but I think all the above will probably solve your problem
as soon as it's ready...
_alex
--
alex black, ceo
en...@tu...
the turing studio, inc.
http://www.turingstudio.com
vox+510.666.0074
fax+510.666.0093
|
|
From: Justin F. <je...@ey...> - 2001-07-26 21:06:55
|
Alex:
I would like a facility in BC that allowed multiple layouts
per group. The reason for this is the felt need to have
some "standard" layouts that are quite common. Just to
give an example, there may be a site that in the "main pane"
(not the master template scope) there is a need for a
standard piece of HTML decoration, text or whatever, such
as maybe a copyright notice, a set of links, a mailto: to
the webmaster or whatever.
Logically, something like the below would be necessary,
namely you need anoth'layout' => array(
'one' => array(
'name' => "example",
'package' => "html.layouts",
),
'two' => array(
'name' => "copyright",
'package' => "html.layouts",
),
'three' => array(
'name' => "webmaster",
'package' => "html.layouts",
),
),
er array level, viz:
'layout' => array(
'one' => array(
'name' => "example",
'package' => "html.layouts",
),
'two' => array(
'name' => "copyright",
'package' => "html.layouts",
),
'three' => array(
'name' => "webmaster",
'package' => "html.layouts",
),
),
and the example layout may have the buffer output, but
the "copyright" and "webmaster" layouts are just
very common bits of HTML and have no Output()
stuff at all....
Right now, if you have standard header_like_things and
footer_like_things in various groups, you must make a
single layout for that group with all the bits and pieces
necessary, even though these bits and pieces make up
a set.
Anyway, I won't try and justify this. I feel this need,
and I suppose that I would like for the rest of the group
to comment on it.
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: Alex B. <en...@tu...> - 2001-07-26 01:14:04
|
hi all, I've changed the ambiguous "options" array key in $gPageDef to be 'params' I've also changed templates/'def' to 'default' which is a lot more clear. best, _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-25 21:06:02
|
hi all, Any takers for implementing a cache of Page output? Pear's cache class looks mature to me, so I think we should use it. If anyone's up for it, I'll make up some design docs for you. best, _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-25 21:02:05
|
hi all, I have 100% access to the pear tree in ext, Init now imports and instantiates the PEAR base class, and PEAR_error. note that $PEAR exists as a global, while PEAR_Error is $Err. I want to maintain $Err as an abstracted object handle so we can switch to differen error handling if necessary. best, _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-25 18:20:37
|
hi all,
It's been a bit quiet on the lists, mostly because there hasn't been any
release activity and we've gone through all of the concepts that are
relevant for the moment...
So, this mail is to give everyone an idea of what's happening next:
-Multi-site makes which can use defaults for a subset of the files
-Standards for browser resource storage in htdocs/resources/*
-Encapsulation scheme for native php templates
-PEAR integration (including pear_error and pear package imports)
-Default module associations with master templates
-bc_edit integration into CVS
-Integrated PHPDoc in the make system
-Final switch from register_globals to the Request class
-xml2php make process for:
-page definitions
-language definitions
-configuration
-datasource definitions
-Multi-language string keys for all files in the source tree.
-XML String repositories
There are also some other developments with xml->xsl->php stuff that I'll
talk about later, once I have some functioning examples.
best,
_alex
--
alex black, ceo
en...@tu...
the turing studio, inc.
http://www.turingstudio.com
vox+510.666.0074
fax+510.666.0093
|
|
From: alex b. <en...@tu...> - 2001-07-23 03:11:50
|
hey all, Anyone on here actually installed a recent version of PEAR? I just got a copy out of CVS on php.net and it is a complete mystery. It looks like PEAR_Error is not actually compiled into the engine, and is no longer php source... As soon as I have this up I'm going to try and make it as "automatic" as possible, and integrate PEAR_Error into the load process. I'm upgrading my mod_php and cli to 4.0.6 at the same time. _a |
|
From: Kristian H. <Kri...@ge...> - 2001-07-19 08:37:47
|
> but I agree bigtime with the "if you're nested more than 3 down, you're > screwed: don't do it. ugh, just got flashbacks about customising the Python scripts in Ultraseek |
|
From: Alex B. <en...@tu...> - 2001-07-19 01:32:21
|
> Tabs are 8 characters, and thus indentations are also 8 characters. > There are heretic movements that try to make indentations 4 (or even 2!) > characters deep, and that is akin to trying to define the value of PI to > be 3. ! I love this! :) > Rationale: The whole idea behind indentation is to clearly define where > a block of control starts and ends. Especially when you've been looking > at your screen for 20 straight hours, you'll find it a lot easier to see > how the indentation works if you have large indentations. Ok, yes this is true. > Now, some people will claim that having 8-character indentations makes > the code move too far to the right, and makes it hard to read on a > 80-character terminal screen. The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, and should fix > your program. yes, I love this even more! > In short, 8-char indents make things easier to read, and have the added > benefit of warning you when you're nesting your functions too deep. > Heed that warning. heheh.. so, I think this: -I like using /t (tab) because you can set it to be displayed however you like it. I prefer flexibility. but I agree bigtime with the "if you're nested more than 3 down, you're screwed: don't do it. :) _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: John D. <jo...@we...> - 2001-07-19 01:21:23
|
Here is an excerpt from the Linux kernel coding style document (see /usr/src/linux/Documentation/CodingStyle): ---[snip]--- Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. ---[snip]--- -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
|
From: Jimmy H. <ji...@ha...> - 2001-07-18 07:45:48
|
Alex, if you haven't already done so, please have a look at hotmail's editor. Pretty nice! |
|
From: alex b. <en...@tu...> - 2001-07-17 05:27:29
|
hi Jimmy, Yes, you can download the r1tarball and have a look at the knowledgebase modules... https://sourceforge.net/project/showfiles.php?group_id=16402&release_id=2667 8 Though, and I must stress this, that version of formbuilder is not entity aware - it's there because we're probably going to rip some of the parts out of it that we find useful. It's good code, and it works, but it's definitely binarycloud r1 stuff. Same with the current TableBuilder. _alex ----- Original Message ----- From: "Jimmy Harlindong" <ji...@ha...> To: <bin...@li...> Sent: Monday, July 16, 2001 7:20 PM Subject: [binarycloud-dev] Example of Form_Builder > Hi alex, > is there any examples on using FormBuilder? > > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Jimmy H. <ji...@ha...> - 2001-07-17 02:20:21
|
Hi alex, is there any examples on using FormBuilder? |
|
From: Alex B. <en...@tu...> - 2001-07-16 19:19:01
|
> It is interesting that my perception of BC, or what I see > as its advantages, and how it is used, seemingly is different > from yours. I see BC as a kind of high-speed "class gatherer" > and the model in my mind is that I, sort of, have one big > virtual file with all the classes I need. Therefore, I "call" other > methods in other classes (cross module). As an example > if I go fetch from a database in several modules and there > are errors (presumedly non-fatal), I wish to have another > module (class) push these warnings on a stack in the > Warning module, and then when it is Output-time for > Warning, Warning->Output() displays them. This functionality > is not unlike your $Debug->CaptureMessage() thingy, > (blessedly you can go to global scope!). > Therefore from any module, I want to call methods or > fetch vars from another module (Class). I think you're stepping over a bit into the domain of libraries, which is why you aren't getting quite what you want. I agree that module communications are important, and I will create mechanisms to facilitate that communication, but it is certainly not a requirement I have encountered even in building complex applications. > You talk about importing/including libraries in the > module to do things. This is certainly possible if > you just need methods that are "self-standing", manipulate > something, return something, and are independant of > any data/data structure/state somewhere else in the platform. That's not true: you can create as many instances of a class as you like and have each of those class instances carry a context. I do that all the time. >> I think this all depends on whether you need to maintain the state of the >> module you need to talk to - i.e. do you need to differentiate between >> individual instances of the same module, or can it just be "any instance" > > Correct. Sometimes I don't care what instance I talk to, but > when I need state, I have to have one instance somewhere that > I can talk to. And that will always be difficult to do. You'll have to know something about the page if you're going to do that. That's ok - but keep that in mind. > 2. Your statement: >> Remember that modules are _only_ intended for presentation - they _are_not_ >> libraries. >> If you need general functionality for your applications, make libraries and >> put them in user/lib/, and include them in your modules as normal. > > This, er, sort of facinates me. I am willing in an eyeblink to > change my "method" of using BC. But I am interested in why you > make that statement, _only_ intended for presentation. Why? > I am trying to evaluate the advantages of that approach. Precisely because of your problems. It doesn't work well to embed all of your logic in "one place" that is also responsible for presentation. If you allow the use of libraries, (i.e. you build your applications that way) a lot of your problems in that regard go away. For example, I have a module which lists something, but part of that list has some data that's derived from the result set of a SQL query. I abstract the "figure-outer" code that makes that derivative data to a library. Your error stack stuff is actually a prime example of something that will be taken care of by the core classes (hopefully PEAR_Error). Modules should hold what context they need to get presentation out the door - they are in a sense responsible for assembling your application from its components (libraries, templates, queries, etc) modules are where all of the tools should be assembled, and their i/o coordinated. > I see advantages of creating what I call "Drone Modules" that do > nothing but, say, collect a data set during Constructor-Time > and another instance that collects another data set during > Constructor-Time. Why? i.e. why have separate modules for each of those operations? I think you're thinking of grains of sand, where I'm thinking about gravel :) Modules are only significant as presentation components - otherwise you're going through much too much trouble for each module. > Then, following I have a a couple of "listers" > in the same group, each instance being told (through options, for > example) which Drone to use for its data set to present. Like > this, I can put up 2 (or N) reports/lists on a page. It is true > what you say that I could include a class in the module that could > then be used to collect a data set, then another from somewhere > else... But why is this "better"? It seems that such coding > diminishes the generality of the module. > > I want to do > +---------------+ +---------------+ > | Mod A: | | Mod B: | > | Control |------>| Data Collect | > | | | | > +---------------+ +---------------+ > | > | > | > v > +---------------+ > | Mod C: | > | Lister | > | | > +---------------+ > > where module A controls things, gets data from module B > and passes it to module C for ultimate display. And, yes, you can do that. But you'll need to do that 'passing' with global variables for the moment, because other things need to come first before I dive into this issue. As far as I am concerned, the lister should be a libaray, and so should the data collector. That way you have Mod A 'control' which is exactly what they are for. > The advantage of this is that I can load many instances > of module B and have each one get a different set of > data, and then maybe A shuffles these data sets around > and passes these data sets to module C, which can > _also_ be multiple, each Lister having been set > up (again by a cross module call) for a different > look and feel. There is no advantage over using a library, just use a different named instance of that library. You can make as many instances of a class as you like, just use a different variable name. So you gain nothing by using a modules (except some pain in the a** trying to get them talking to each other) > Now A _may_ not have Output(), B certainly does not > have output, and C _may_ do all the output, and if > there are many instances of B and C, I may then > have 23 reports presented on the page, each with > a different dataset and different look and feel. > And, to go blue-sky, what if I wish to use GD > and draw 23 different bar charts? then have one module responsible for the output, and have 'graph profiles' which are loaded by the module at runtime. > And, for this, I only have to generalize module B > and module C, they are, for me, my "library" in > functionality. I keep the unique bits in module A. > And, I retain a kind of ability to change things > dynamically. I want to make sure this is 100% clear: you are gaining nothing by using a module in place of a library. > MAYBE I AM APPROACHING THIS ALL WRONG. I donno. You aren't. And I intend to 'support' what you are doing: however, you'll have to wait for a while if you want it to be elegant. For now, use global variables to do your passing, and you'll be fine. > I am cutting the salami in a certain way, you are > suggesting another. It just seems that to write > an "application" that is as complex as a dynamic > report generator, I would have to cut the salami > in my way.... I will give it a think. You wouldn't, but I am not in the business of dictating. I'm not saying "modules can't be used as libraries" I'm saying "the way I orginally thought about this is that modules would not be libraries... which is why you aren't finding toold to support what you're doing" but I _do_ see the value of that you are trying to do. so I'll make it happen... but not yet. > And Jimmy, I hope that I was not the cause of > you bailing out. Alex will be pissed off at me. > But don't go away. It is a bit of a pain in the > ass to do things right now with this construction > site, but ultimately, it will pay off handsomely. :) _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: John P. C. <jp...@jp...> - 2001-07-16 16:28:23
|
On Mon, Jul 16, 2001 at 12:49:29PM +0200, Andreas Aderhold wrote:
>
> Add(&$values) does the validation, right !?
Yes, the EntityManager::Add() uses information in the entity defintion to
validate the input. You can, of course, override this to do any additional
validation as well.
> And the values I pass to EntityManager::Add($values) have the filed names +
> values for my tables that are defined by this entity?
>
> But what if the entity spans more than one table? A common construct in my
> db is for example:
This is fine. The entity is a logical object (of one or more entities) that
map to zero or more database tables. The relationships to other tables are
defined within the entity definition, so that all the basic queries are
automatically generated.
> $values array(
> 'newsId' => 1,
> 'userId' = 22,
> 'categoryId = 10,
> 'text' => "Blah",
> 'resourceId' = 1,4,3
> );
>
> The manager then connects the resource id 1,4,3 with the news 1 updating the
> tables news and newsresources!?
We do things like:
myobj = array (
'FIELD1' => 'A',
'FIELD2' => 'B',
'MAILADDRESS' => array (
'STREET' => 'Foo Ave.',
'CITY' => 'Houston',
'STATE' => 'TX',
)
);
In this case there are two entities encapsulated in one. The toplevel object
and the mailaddress. The joins between the two are automatically created and
all the queries for selecting, inserting, deleting, etc. are created for you.
> That IS really groovy!!!!!
Yes it is.
Gotta run to work on all this craziness.
HTH.
jpc
|
|
From: Andreas A. <a.a...@th...> - 2001-07-16 11:00:41
|
Hi John,
> class TCategory {
> var $categoryId;
> var $name;
> var $parentId;
>
> function selfCheck() {
> ..
> }
> }
>
> class EtyCategory {
> function Add() {
> MetabaseStuff;
> }
> ...
> }
> Originally, we thought of it like that, with the classes containing the
state
> of the entity. But it quickly became apparent that the usefulness of that
> really didn't exist the way our system works. The managers are more
"session"
> based. They contain no state and only handle the operations of an entity
like
> Add, Set, Get, GetList, Delete and other BL functions a developer might
add.
Yepp. Thats more or less how I do it now. I've a class say,
"IfCategoryAdmin" that handles the administration of categories (renders
page (cur. smarty) and acting to form input). This class will split up to
differend BC modules, later (e.h. regex filter operations, orderby are
common to all my scripts).
The interface class uses a manager class "MgrCategory" that handles the
queries using the above TCategory "type". Actually i've splitted the
validation routines to another class TCategoryValidator that extends the
TCategory. This is, because I don't want to have the validation routines in
the array holding the containers = each row I fetch from db.
For example I get from the post an asoc array $formdata[]. I pass this to
the validator that checks it back, if ok, I create an object of Tcategory
and pass it to the manager, then trigger Add(), Delete() etc.
That's how I currently manage the database stuff. I feel thats a bit
overhead and unneccessary work caus I have to write a manager for each table
and the corresponding tables and its error prone. So I'm very excited to see
the entity manager.
>Class TCategoryManager extends EntityManager {
> ...
> function Add(&$values) {
> // polish up data as desired in the derived class
> ... your code ...
>
> return EntityManager::Add($values);
> // returns true/false
> }
>}
Add(&$values) does the validation, right !?
And the values I pass to EntityManager::Add($values) have the filed names +
values for my tables that are defined by this entity?
'categoryId' => 1,
'name' => "Music",
'parentId' => 0
But what if the entity spans more than one table? A common construct in my
db is for example:
news (newsId, userId, categoryId)
newsresources <- linktable (newsId,resourceId)
resources (resourceId, etc)
If i understand right I define this connection somewhere in the entity named
"news" and then pass
$values array(
'newsId' => 1,
'userId' = 22,
'categoryId = 10,
'text' => "Blah",
'resourceId' = 1,4,3
);
The manager then connects the resource id 1,4,3 with the news 1 updating the
tables news and newsresources!?
That IS really groovy!!!!!
>$values = array (
> 'CATEGORYID' => 'A',
> 'NAME' => 'My Name',
> 'PARENTID' => 'B'
>);
> $rval = $myMgr->Add($values);
currently i'm doing like this in the UI script (modified is asoc array):
$values = new TCategory($Request->getVar("modified"))
$rval = $myMgr->Add($values);
or
$list = $myMgr->GetByRegex($regex)
where $list is an array of TCategory objects.
> The Editor/Lister seamlessly integrate with the Managers and calls the
> Add/Set/Get with the appropriate values. So, in most cases you don't have
> to go around building these arrays.
Ok, thats clear. Now, to make my app as portable as possible, what shall I
do? I guess:
- frist, sikp to work with this type objects (TCategory, TCategoryValidator)
- gather the values from user and assemble array as shown above
- pass this array to my current manager $myMgr->Add($values);
- my manager handles this array and does the querys that
I currently have to write by hand. Later I just replace the database
handling with ety manager calls.
Thanks
Andi
|
|
From: Justin F. <je...@ey...> - 2001-07-16 04:17:24
|
Alex:
Hmm, some info/observations.
You asked:
1. Why are you calling methods in one module from another module?
It is interesting that my perception of BC, or what I see
as its advantages, and how it is used, seemingly is different
from yours. I see BC as a kind of high-speed "class gatherer"
and the model in my mind is that I, sort of, have one big
virtual file with all the classes I need. Therefore, I "call" other
methods in other classes (cross module). As an example
if I go fetch from a database in several modules and there
are errors (presumedly non-fatal), I wish to have another
module (class) push these warnings on a stack in the
Warning module, and then when it is Output-time for
Warning, Warning->Output() displays them. This functionality
is not unlike your $Debug->CaptureMessage() thingy,
(blessedly you can go to global scope!).
Therefore from any module, I want to call methods or
fetch vars from another module (Class).
You talk about importing/including libraries in the
module to do things. This is certainly possible if
you just need methods that are "self-standing", manipulate
something, return something, and are independant of
any data/data structure/state somewhere else in the platform.
> I think this all depends on whether you need to maintain the state of the
> module you need to talk to - i.e. do you need to differentiate between
> individual instances of the same module, or can it just be "any instance"
Correct. Sometimes I don't care what instance I talk to, but
when I need state, I have to have one instance somewhere that
I can talk to.
> If it's the former, I think in future we'll deal with that (a manager) - but
> you can do it now with module ids (your tag thing, I implemented it)...
Yes, I am doing that too, it works quite well "in parallel".
2. Your statement:
> Remember that modules are _only_ intended for presentation - they _are_not_
> libraries.
> If you need general functionality for your applications, make libraries and
> put them in user/lib/, and include them in your modules as normal.
This, er, sort of facinates me. I am willing in an eyeblink to
change my "method" of using BC. But I am interested in why you
make that statement, _only_ intended for presentation. Why?
I am trying to evaluate the advantages of that approach.
I see advantages of creating what I call "Drone Modules" that do
nothing but, say, collect a data set during Constructor-Time
and another instance that collects another data set during
Constructor-Time. Then, following I have a a couple of "listers"
in the same group, each instance being told (through options, for
example) which Drone to use for its data set to present. Like
this, I can put up 2 (or N) reports/lists on a page. It is true
what you say that I could include a class in the module that could
then be used to collect a data set, then another from somewhere
else... But why is this "better"? It seems that such coding
diminishes the generality of the module.
I want to do
+---------------+ +---------------+
| Mod A: | | Mod B: |
| Control |------>| Data Collect |
| | | |
+---------------+ +---------------+
|
|
|
v
+---------------+
| Mod C: |
| Lister |
| |
+---------------+
where module A controls things, gets data from module B
and passes it to module C for ultimate display.
The advantage of this is that I can load many instances
of module B and have each one get a different set of
data, and then maybe A shuffles these data sets around
and passes these data sets to module C, which can
_also_ be multiple, each Lister having been set
up (again by a cross module call) for a different
look and feel.
Now A _may_ not have Output(), B certainly does not
have output, and C _may_ do all the output, and if
there are many instances of B and C, I may then
have 23 reports presented on the page, each with
a different dataset and different look and feel.
And, to go blue-sky, what if I wish to use GD
and draw 23 different bar charts?
And, for this, I only have to generalize module B
and module C, they are, for me, my "library" in
functionality. I keep the unique bits in module A.
And, I retain a kind of ability to change things
dynamically. You may argue that you can make
conditional includes in module A, I am sure that
would work. But I see advantages of how I wish
to do it right now, I will have to think a bit
on how you are suggesting that "modules should not
be used as libraries". My "method" allows for
the possibility to retain state easier, I think.
MAYBE I AM APPROACHING THIS ALL WRONG. I donno.
I am cutting the salami in a certain way, you are
suggesting another. It just seems that to write
an "application" that is as complex as a dynamic
report generator, I would have to cut the salami
in my way.... I will give it a think.
And Jimmy, I hope that I was not the cause of
you bailing out. Alex will be pissed off at me.
But don't go away. It is a bit of a pain in the
ass to do things right now with this construction
site, but ultimately, it will pay off handsomely.
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: alex b. <en...@tu...> - 2001-07-16 02:29:40
|
> Justin, > > I have tried only briefly to go beyond normal "wow the hello world > works" test on BC. I found it very hard to do what you just mentioned. > For example I wanted to use a 'database' module to perform the query but > you guessed it, it's hard to refer to the module without reverting to > using a global variable. Remember that modules are _only_ intended for presentation - they _are_not_ libraries. If you need general functionality for your applications, make libraries and put them in user/lib/, and include them in your modules as normal. Modules are _only_ for getting output to a page. Modules can include header redirects, etc - but it's bad form to have a silent logic-only module. And it will be a pain in the ass to work with :) I don't have any "very" complex modules in any of my projects, including large projects. There is never a reason to put that much code in a module. Of course you can, if you want. > So I have decided to leave BC for now, and wait till Alex has sorted out > the "Manager" classes and integrated a more complete working system > before I shall spend my time looking at it again. I suggest you read the above. Modules are not the be-all-and-end-all. > I particularly find that it ridiculous and tedious to have to write 4 > different files to create one simple page. (the htdocs, the layout > template, the module, and module specific layout). You don't need a layout template per page. As opposed to? How would you suggest cutting down that number, but retaining all the abilities of the system? Also, remember that doing page definitions will be made a hell of a lot easier by a page editor, and by the fact that pages will be done in XML. Each module will have a declaration file (probably similar to pear's package declaration format) which will allow a page editor to provide the user with a list of modules. best, _alex |
|
From: alex b. <en...@tu...> - 2001-07-16 02:23:11
|
> Are any of you building sites with BC and using inter-module
> "communication", that is, fetching variables or calling
> methods in another module with the construct:
>
> $return = $Page->modules[group][idx]->foo();
>
> or
> $some_var = $Page->modules[group][idx]->bar;
>
> ?????????
>
> IF YOU ARE DOING THIS, DOES IT WORK FOR YOU?
I am not doing that. And of course it would not work very well, because it
is 100% relying on the load order, which is of course, page specific.
Why are you calling methods in one module from another module?
> Now, if you are concerned or interested, you can read
> farther. I have been having all kinds of strangeness
> trying to make this "intermodule" communications work,
> which should just be nothing more, except through
> a couple more dereferences, than calling a method
> in a class or fetching a var in a class in the
> same namespace.
I think this all depends on whether you need to maintain the state of the
module you need to talk to - i.e. do you need to differentiate between
individual instances of the same module, or can it just be "any instance"
----
If it's the former, I think in future we'll deal with that (a manager) - but
you can do it now with module ids (your tag thing, I implemented it)...
Or, really for 90% of things, global variables.
> 1. top has two modules, EyeLibrary
> and DataDictionary
> 2. main has two modules, Lister and
> TestMain
> 3. left has one module, TestNavLeft
> 4. bottom has two modules, Warning and
> Blank
>
> SO, if in the TestMain module I put this
> little bit of debugging code
>
> global $Page;
> if(1) {
> echo "<pre>";
> $group = "top";
> $idx = 0;
> $item =& $Page->modules[$group][$idx];
> if (empty($item)) { printf("EMPTY reference in [%s][%d]",$group,$idx); }
> print_r($item);
> echo "</pre>";
>
> What is rendered is fine, namely
> eyelibrary Object
> (
> [options] => appears 1
> )
>
> which is expected, since EyeLibrary is the first in the group.
>
> if I change group to main and idx remains at 0,
> what I get is expected, namely the Lister
>
> lister Object
> (
> [tableOptions] => Array
> snip
>
> BUT IF I LOOK FOR group = "bottom", idx = 0,
> I get:
> EMPTY reference in [bottom][0]
Have you looked at a printf of the $Page object to see if the thing you are
making reference to exists?
> This is same for the group 'left". In other
> words, I cannot "see" anything in groups 'left'
> or 'bottom".
>
> Any ideas? I have some VERY WILD ones, like Zend
> sees, somehow, the method of instantiation that
> BC uses as a recursion, and Zend is throwing something
> away after three levels.
I really, really, _really_ doubt it has _anything_ to do with the zend
engine.
:)
_a
|
|
From: Jimmy H. <ji...@ha...> - 2001-07-16 01:57:18
|
Justin, I have tried only briefly to go beyond normal "wow the hello world works" test on BC. I found it very hard to do what you just mentioned. For example I wanted to use a 'database' module to perform the query but you guessed it, it's hard to refer to the module without reverting to using a global variable. So I have decided to leave BC for now, and wait till Alex has sorted out the "Manager" classes and integrated a more complete working system before I shall spend my time looking at it again. I particularly find that it ridiculous and tedious to have to write 4 different files to create one simple page. (the htdocs, the layout template, the module, and module specific layout). Regards, Jimmy |
|
From: Justin F. <je...@ey...> - 2001-07-15 23:12:51
|
Alex/Guys:
Now I know it is usually too much to expect for others to
run a piece of code or search for a bug if it is not directly
affecting you. This is not a complaint, only
an observation of reality But, first, I
will ask a question to the group.
Are any of you building sites with BC and using inter-module
"communication", that is, fetching variables or calling
methods in another module with the construct:
$return = $Page->modules[group][idx]->foo();
or
$some_var = $Page->modules[group][idx]->bar;
?????????
IF YOU ARE DOING THIS, DOES IT WORK FOR YOU?
Now, if you are concerned or interested, you can read
farther. I have been having all kinds of strangeness
trying to make this "intermodule" communications work,
which should just be nothing more, except through
a couple more dereferences, than calling a method
in a class or fetching a var in a class in the
same namespace.
I have experienced all kinds of strangeness. I have
posted before on this. I have spent days looking for
the "problem", and and starting to be suspicious of
Zend as well as my own sanity.
Now I have a $bc_page with 4 groups.
1. top has two modules, EyeLibrary
and DataDictionary
2. main has two modules, Lister and
TestMain
3. left has one module, TestNavLeft
4. bottom has two modules, Warning and
Blank
SO, if in the TestMain module I put this
little bit of debugging code
global $Page;
if(1) {
echo "<pre>";
$group = "top";
$idx = 0;
$item =& $Page->modules[$group][$idx];
if (empty($item)) { printf("EMPTY reference in [%s][%d]",$group,$idx); }
print_r($item);
echo "</pre>";
What is rendered is fine, namely
eyelibrary Object
(
[options] => appears 1
)
which is expected, since EyeLibrary is the first in the group.
if I change group to main and idx remains at 0,
what I get is expected, namely the Lister
lister Object
(
[tableOptions] => Array
snip
BUT IF I LOOK FOR group = "bottom", idx = 0,
I get:
EMPTY reference in [bottom][0]
This is same for the group 'left". In other
words, I cannot "see" anything in groups 'left'
or 'bottom".
Any ideas? I have some VERY WILD ones, like Zend
sees, somehow, the method of instantiation that
BC uses as a recursion, and Zend is throwing something
away after three levels.
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: John P. C. <jp...@jp...> - 2001-07-15 17:11:58
|
On Sun, Jul 15, 2001 at 02:55:48PM +0200, Andreas Aderhold wrote:
> Hmm. Like that?
Not quite, see below.
> class TCategory {
> var $categoryId;
> var $name;
> var $parentId;
>
> function selfCheck() {
> ..
> }
> }
>
> class EtyCategory {
> function Add() {
> MetabaseStuff;
> }
> ...
> }
Originally, we thought of it like that, with the classes containing the state
of the entity. But it quickly became apparent that the usefulness of that
really didn't exist the way our system works. The managers are more "session"
based. They contain no state and only handle the operations of an entity like
Add, Set, Get, GetList, Delete and other BL functions a developer might add.
For example:
Class TCategoryManager extends EntityManager {
...
function Add(&$values) {
// polish up data as desired in the derived class
... your code ...
return EntityManager::Add($values);
// returns true/false
}
}
// values would be past in from a client of the Manager (UI, xml request,
etc). It would look like this:
$values = array (
'CATEGORYID' => 'A',
'NAME' => 'My Name',
'PARENTID' => 'B'
);
$rval = $myMgr->Add($values);
So, basically you are saying to the manager, "Here is some data I have.
Please Add it, as only you know how."
The Editor/Lister seamlessly integrate with the Managers and calls the
Add/Set/Get with the appropriate values. So, in most cases you don't have
to go around building these arrays. You only have to make the initial entity
definition, and everything else just works. I may be oversimplifying a little,
but not too much actually.
HTH,
jpc
|
|
From: alex b. <en...@tu...> - 2001-07-15 16:42:12
|
this is cool. so, I think I will again wait to see, but this is an extremely good sign. :) _a ----- Original Message ----- From: "Stig S. Bakken" <Sti...@fa...> To: "Alex Black" <en...@tu...> Cc: <pea...@li...> Sent: Sunday, July 15, 2001 4:00 AM Subject: Re: [PEAR-DEV] Re: BinaryCloud should be let into PEAR withothers as well.... my 2cents > Alex Black wrote: > > > > >> Inclusion should not necessarily mean "endorsement" it should mean "base set > > >> of quality requirements met" > > >> > > > > > > Ahh.. But I get the feeling it does. > > > > Right. I think that's a mistake but that's me and this isn't the place for > > that. Did that once (the whole proving my point thing) and I only needed to > > do that once :) > > I'm aware of this, and I too probably have a few spots on my record for > doing this kind of thing, but I strive not to. It will be less > difficult when we have the distribution framework up (I want my hand > back dammit), then distributing a PEAR class will no longer be > equivalent with "hosted at php.net and pear-dev will rip you to shreds > if you misindent one function" :) > > - Stig > |
|
From: Andreas A. <a.a...@th...> - 2001-07-15 12:55:59
|
Hi Alex, > I'm thinking about doing multi-site makes this way. > This is very, very early thinking so please bear that in mind :) ----- > The current contents of binarycloud/user/ is moved into > binarycloud/user/default/ (default would be the "default" distro site name) Sounds good to me. > binarycloud/ > user/ > default/ > ** current contents of binarycloud/user/* ** > site_name/ > other_site/ > smallsite/ I like that organization MUCH more than the binarycloud/ user/ site_1/ site_2/ site_3/ you suggested earlier. Ist clear an you will have user/default/ and user/site_name/ in the build tree. That feels natural to me. > Also, I would like to try and structure the makefile so there is only one, > top level user/Makefile - I don't want to have to maintain (x) Makefiles, or > a directory of directories ala: Right, that's a mess. But that requires strict obedience to the directory structure at least in /user/sitename/*, why not? This ensures that maybe people could share whole sites without trouble. >binarycloud/ > user/ > site_name/ > _but_ - if there is a missing directory from binarycloud/user/site_name/, > we'd grab user/default/missing_directory_name/ and include it in the build > version of binarycloud/user/site_name/ Wow, thats cool. > So, for example, you could leave out the user/site_name/conf/ directory, and > know that it would be grabbed from user/default/conf/ at make-time and put > in user/site_name/conf/. That would be great for maintaining a 'base' > config. Ok, but that mechanism should also work for individual files not only for the directories. All in all I like this organization. It's clear and self explaining. Andi |
5 messages has been excluded from this view by a project administrator.
