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-08-23 17:13:37
|
>> version is marked as inactive. This effectively will allow us to build >> an interface with the ability for automatic version control, unlimited >> undo, and so on. >> >> Having read through the pre-release docs on r2, it doesn't look like >> there's anything in the core product which will facilitate this. On the >> other hand, there also doesn't seem to be anything which should hinder >> this. > > We have a few versioned entities. We basically implement and override the > necessary methods in the derived class. For example, the > VersionedObjectManager::Set() can do whatever you want or you can just call > the > parent::Add() and get the system default behaviour. It's not automatic, but > functional. > >> Seems to me that this functionality may belong in the core product, with >> parameters in the XML entity definition files that would enable >> versioning/history automatically. Comments? > > If it's possible to spec out the behaviour of a generic versioned object in a > way that is useful for the majority of the cases, then this is very feasible. > > jpc can you forward this thread? I don't see it? -a |
|
From: Alex B. <en...@tu...> - 2001-08-23 17:12:25
|
> > does this work? > > SELECT newsid FROM news > > I like this to distinguish alias/table.field stuff from SQL STATEMENTS. works fine. so, I think everything I said before, but with lowercase: :: For modules to be distributed with binarycloud or available from the > (upcoming) module repository, you must: > -Use field and table/entity names with less than 32 chars. > -Use lowercase for all field and table/entity names. > -Verify that your SQL & Schemas work with Oracle, MySQL, and > PostgreSQL. |
|
From: Peter B. <re...@f2...> - 2001-08-23 15:59:50
|
Hi, Has anyone yet worked out which modules need to be downloaded? Also, do I download the source or the numbered package for each? Thanks, Peter. |
|
From: Andris S. <li...@ap...> - 2001-08-23 14:59:46
|
> I applied your zip and the changes in the Makefie.in, but now I get this :( > in user/htdocs > Error in argument 1, char 3: option not found At least we have some progress... Another error message (:>)... Could you please check 1) whether it now gets to the xml2php file (i.e. try to echo something at the beginning of the file, see if something comes out). 2) whether you have enabled register_argc_argv and register_globals in your php.ini file. 3) if you're Unix user, there should be #!/usr/local/php4/bin/php -q, but not #!c:/php/php.exe -q at the beginning of xml2php.php Andris Spruds |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 13:24:52
|
Hi Alex, All, I've done a sample of a query definition file. The definitons are translated to php an can be easiely loaded via import(). Please have a look. Thoughts? Comments? Andi |
|
From: Konstantin C. <Kon...@da...> - 2001-08-23 12:30:47
|
Andreas Aderhold wrote:
> > for example, in oracle both of these queries work:
> > select newsid from news;
>
> How are the column headers returned for this query also in lowercase? Or in
> uppercase? In MySQL they are returned as typed in the query.
>
Wouldn't it be better just to define column and table names as
case-insensitive and always uppercase/lowercase them in QueryManager before
doing a MetaBase query?
Then, the user will be free in choosing their naming convention.
Doesn't Oracle (or some other databases) really support '_'? In that case,
especially, allowing the user to mix upper and lower cases in the names would
be nice. E.g. "FurbeeId" is more readable than "furbeeid" or "FURBEEID".
Just my 2 pence :-)
--
* * Konstantin Chuguev Francis House
* * Application Engineer 112 Hills Road
* Tel: +44 1223 302992 Cambridge CB2 1PQ
D A N T E WWW: http://www.dante.net United Kingdom
|
|
From: Andreas A. <a.a...@th...> - 2001-08-23 12:14:30
|
Hi Alex, > for example, in oracle both of these queries work: > select newsid from news; How are the column headers returned for this query also in lowercase? Or in uppercase? In MySQL they are returned as typed in the query. Andi |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 12:11:31
|
Hi Andris,
> Let me know if anyone can build the thing now, because I'm not going to
> update the CVS with the new version of xml2php & friends &
> makefiles unless
> I hear at least one success story (:>)
I applied your zip and the changes in the Makefie.in, but now I get this :(
...
in user/htdocs
Error in argument 1, char 3: option not found
Error in argument 1, char 3: option not found
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>] | {<file> [args...]}
<<<the php help screen >>>
Error in argument 1, char 3: option not found
Error in argument 1, char 3: option not found
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>] | {<file> [args...]}
<<<the php help screen >>>
make[1]: *** [xml_page_def] Error 1
make: *** [langs] Error 2
[andi@hal r2]$
Andi
|
|
From: Andreas A. <a.a...@th...> - 2001-08-23 12:11:26
|
Hi Alex, > This is the source tree I expect we'll have when r2/final is > out... I'm sure some of you will have questions re: this list of > classes, etc. Please feel free. > mod > example_module ... > js/ > css/ > images/ What do you think about putting these into mod/example_module/resources/* To keep the structure more clear. > This is because make will use the naming conventions below to move files > from module and other directories into a single location. That means files > must not have naming conflicts, etc - but it keeps the source > tree, and the installation process simple. Does this mean that each image must have a uniqe name? So module "foo" uses a image called edit.gif and module "bar" must not have a image called edit.gif!? Or is this seperated in the build tree? > -Something.lang.xml will be used by LangKeyer at make-time to key in > nagive-language strings into source files. Will this work for js/htc files too? Or will this be processed like Something.lang_code.js ? > -Something.lang_code.php (i.e. Something.de.php or Something.en.php) > means the file will replace Something.php in same directory when the > language code is the same as lang_code. Useful for writing the same module > that does different things based on the location/language. What about media files: Something.lang_code.gif Something.lang_code.jpg Something.lang_code.mpeg ... Andi |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 10:30:24
|
Hi Alex, > My point is that if we establish fairly restrictive standards about table > and field naming, we can get around those problems and ensure > compatibility between oracle, mySQL, and Postgres: Agreed if those conventions do really work with all Metabase supported dbms. Or at least with the most widely used ones. I would add Informix to the list above. > Re: the above, I'd prefer to have something that works with a standard, > instead of trying to build code that works with 'everything'. Ok, I see your point. I'm not a db expert an my experience with different dbms are limited. Would a standard proposed in the other mail work with most dbms without trouble? What does Manuel think? > I'm not saying QueryManager should process incoming queries (like > strtoupper) but I think we should standardize those names elsewhere in the > system. Ok, and everybody !must! strictly obey. I.e. writing a query with mysql SELECT foo FROM bar will return the columnheader "foo" even if the field ist named "FOO". So the queries must entirely be written UPPERCASE. Andi |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 10:30:20
|
Hi Alex, > hmm, on second thought I'd rather require _lowercase_ field name that > UPPERCASE I think thats much better uahh: SELECT NEWSID FROM NEWS hard to read > for example, in oracle both of these queries work: > select newsid from news; > select NEWSID from NEWS; does this work? SELECT newsid FROM news I like this to distinguish alias/table.field stuff from SQL STATEMENTS. Andi |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 10:30:18
|
Hi Alex, > Right, but isn't that a lot of work for not much benefit? And where to we > store the metadata, in the Entity definition? > > <field> > <name>LongMixedCaseFieldNameWithNoStandard</name> > <short_name>LONGMIXED</short_name> > </field> Hmm. That looks crappy. Ok, forget about this idea. > -I don't want QueryManager to 'enforce' any field naming or other > standards. I don't want enforcement anywhere in the system. > -What I would like to enforce with scripts, etc is this: > > :: For modules to be distributed with binarycloud or available from the > (upcoming) module repository, you must: > -Use field and table/entity names with less than 32 chars. > -Use CAPS for all field and table/entity names. > -Verify that your SQL & Schemas work with Oracle, MySQL, and > PostgreSQL. > Does that sounds reasonable to everyone? Yes. It does :) Andi |
|
From: Andreas A. <a.a...@th...> - 2001-08-23 10:30:09
|
Hi Alex, > Given that MySQL is more flexible than oracle regarding field names, I > suggest we adhere to oracle's naming conventions. Ok. Fine. > -All field and table names are UPPERCASE What with database names and queries? I guess also UPPERCASE. Andi |
|
From: John P. C. <jp...@jp...> - 2001-08-23 05:07:54
|
On Sat, Sep 22, 2001 at 11:24:42PM -0400, Alok K. Dhir wrote: > > version is marked as inactive. This effectively will allow us to build > an interface with the ability for automatic version control, unlimited > undo, and so on. > > Having read through the pre-release docs on r2, it doesn't look like > there's anything in the core product which will facilitate this. On the > other hand, there also doesn't seem to be anything which should hinder > this. We have a few versioned entities. We basically implement and override the necessary methods in the derived class. For example, the VersionedObjectManager::Set() can do whatever you want or you can just call the parent::Add() and get the system default behaviour. It's not automatic, but functional. > Seems to me that this functionality may belong in the core product, with > parameters in the XML entity definition files that would enable > versioning/history automatically. Comments? If it's possible to spec out the behaviour of a generic versioned object in a way that is useful for the majority of the cases, then this is very feasible. jpc |
|
From: Alok K. D. <al...@dh...> - 2001-08-23 03:24:52
|
Hello all - I'm seriously considering adopting r2 as the basis for a fairly sophisticatede knowledge management system which will manage several object classes (entities) including documents, events, people, tasks, etc. One of the project requirements is full version control/edit histories on any object data. I.e. when you make edits to object data and save it, the changed object is stored as a 'new' object, with a same unique identifier as the previous version, and the previous version is marked as inactive. This effectively will allow us to build an interface with the ability for automatic version control, unlimited undo, and so on. Having read through the pre-release docs on r2, it doesn't look like there's anything in the core product which will facilitate this. On the other hand, there also doesn't seem to be anything which should hinder this. I'm curious to hear comments from the developer community on the feasibility of implementing this requirement using bc r2. Seems to me that this functionality may belong in the core product, with parameters in the XML entity definition files that would enable versioning/history automatically. Comments? Thanks. Al |
|
From: Andris S. <an...@do...> - 2001-08-22 23:12:26
|
> I'm getting this:
> /bin/sh: /home/alex/r2/binarycloud/build/en/htdocs: is a > directory
> make: *** [xml_page_def] Error 126
> alex@core htdocs>
Just checked in all binarycloud tree and tried to document the changes
needed
for xml2php to work.
I got the same error before I remembered I changed /binarycloud/makefile.in
as well...
Part of it looks like this:
GETPKG=$(TOOLS_DIR)/pk2dir.pl
INSTALLCODE=$(TOOLS_DIR)/installcode.sh
PROCESSPREPEND = $(TOOLS_DIR)/processprepend.php
But it should contain one more line which defines the location of xml2php,
so:
GETPKG=$(TOOLS_DIR)/pk2dir.pl
INSTALLCODE=$(TOOLS_DIR)/installcode.sh
PROCESSPREPEND = $(TOOLS_DIR)/processprepend.php
XML2PHP= $(TOOLS_DIR)/xml2php.php
Also, it might be an good idea to add XMLUtils.php to the list of copied
files at /binarycloud/base/lib/makefile
Let me know if anyone can build the thing now, because I'm not going to
update the CVS with the new version of xml2php & friends & makefiles unless
I hear at
least one success story (:>)
Bellow the history of changes needed with the latest bc version from CVS:
/binarycloud/makefile - changed the order of the build process
/binarycloud/makefile.in - added XML2PHP= $(TOOLS_DIR)/xml2php.php
/binarycloud/base/utils/processprepend.php - added #!c:/php/php.exe -q
at the beginning of the file
/binarycloud/user/makefile - added xml2php calling functions
/binarycloud/base/lib/makefile - added XMLUtils.php to the list of files
copied
Andris Spruds
|
|
From: Alex B. <en...@tu...> - 2001-08-22 21:30:50
|
hmm, on second thought I'd rather require _lowercase_ field name that UPPERCASE just because I (and I think many others) find them to be easier to read. for example, in oracle both of these queries work: select newsid from news; select NEWSID from NEWS; _a >>> Respective for the XML complement. So QueryManager can loop over >>> the indexed arrays and generate an asoc array like: >>> >>> $buffer[rownumber] = array( >>> "Name1" => Datafromverlongcolumn1, >>> "Name" => Datafromverylongcolumn2 >>> ); >> >> Forgot to mention this. Using this method makes fetching result metadata >> obsolete. That would reduce db load and saving time, I guess. >> >> But the main point is to get around truncation. > > Right, but isn't that a lot of work for not much benefit? And where to we > store the metadata, in the Entity definition? > > <field> > <name>LongMixedCaseFieldNameWithNoStandard</name> > <short_name>LONGMIXED</short_name> > </field> > > egh! :) > > --- > > I rethought an earlier message, so: > > -I don't want QueryManager to 'enforce' any field naming or other > standards. I don't want enforcement anywhere in the system. > -What I would like to enforce with scripts, etc is this: > > :: For modules to be distributed with binarycloud or available from the > (upcoming) module repository, you must: > -Use field and table/entity names with less than 32 chars. > -Use CAPS for all field and table/entity names. > -Verify that your SQL & Schemas work with Oracle, MySQL, and > PostgreSQL. > > > Does that sounds reasonable to everyone? > > _a > > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-08-22 21:26:37
|
attached, differences: - <trim> and <format> are gone - these should be a processor and validator, respectively. - added <params> to validators and processors. very nearly complete... anyone else have comments? best, _alex |
|
From: Alex B. <en...@tu...> - 2001-08-22 21:23:28
|
hi all,
This is the source tree I expect we'll have when r2/final is out... I'm sure
some of you will have questions re: this list of classes, etc. Please feel
free.
best,
_alex
Base
---------------------
init
Init
core
Auth
Perm
Page
Debug
Lang
Request
Sess
Err -> PEAR_Error
mgr
EntityManager
QueryManager
TemplateManager
MessageManager
EventManager
PolicyManager
JSRequestManager
CSSRequestManager
validators/
NoTagsValidator
NoLineBreaksProcessor
NoEntitiesValidator
OnlyCharsValidator
OnlyTagListValidator
CharsetValidator
DateValidator
CurrencyValidator
DecimalValidator
IntegerValidator
TimeValidator
ZipCodeValidator
PhoneNumberValidator
EmailAddressValidator
PasswordValidator
CountryValidator
StateValidator
FASTASequenceValidator
.... suggestions here?
processors/
CharsetProcessor
RegexProcessor
RemoveEntitiesProcessor
EncodeEntitiesProcessor
RemoveTagsProcessor
AllowOnlyTagListProcessor
TrimProcessor
RemoveLineBreaksProcessor
AddLineBreaksProcessor
AllowOnlyCharListProcessor
FormatDateProcessor
FormatCurrencyProcessor
FormatPhoneNumberProcessor
FormatCountryProcessor
FormatStateProcessor
.... suggestions here?
bldr
FormBuilder
ListBuilder
WizardBuilder
TreeBuilder
CalendarBuilder
EmailBuilder
FaxBuilder
PDFBuilder
PageDefBuilder
.... suggestions here?
UIControlBuilder
uicontrols/
TextBoxControl
WindowStatusControl
PasswordControl
TextareaControl
MultiTextBoxControl
PulldownControl
SelectBoxControl
RadioButtonControl
CheckBoxControl
HrefControl
ImageControl
DateControl
CurrencyControl
ButtonControl
TextHeaderControl
OrderedTextHeaderControl
ImageHeaderControl
RowControl
PaginationControl
SimpleListControl
.... suggestions here?
lib
ClientSniffer
HTMLMimeMail
SMTP
Timer
XMLUtils
Webalizer
Htdig
LangKeyer
...
utils
xml2php
php2xml
pk2dir
processprepend
installcode
langkey2string
User
---------------------
conf
Configuration
Datasources
Languages
Operations
roles/
GodRole
AdminRole
etc
htdocs
resources
images
js
css
edit
lib
user-specific proprietary libs
mod
example_module
ExampleModule
AnotherExampleModule
tmpl/
lang/
qry/
ent/
evt/
msg/
js/
css/
images/
tmpl
html
email
pdf
ps
xml
wml
etc..
What we don't need in the source tree:
user/cache
user/db
user/lang
user/roles
The build tree:
---------------------
lang_code
binarycloud
core
init
lib
mgr
bldr
ext
pear
metabase
vagrant
etc
htdocs
resources
...
user
cache
conf
roles
db
schema
before
dump
qry
mod
tmpl
ent
evt
msg
*Note how the build tree contains many more directories, like ent, msg, etc.
This is because make will use the naming conventions below to move files
from module and other directories into a single location. That means files
must not have naming conflicts, etc - but it keeps the source tree, and the
installation process simple.
Naming 'special' files for processing by make:
---------------------
-Something.ent.xml = entity xml definition
-Something.qry.xml = query xml definition
-Something.form.xml = form xml definition
-Something.list.xml = list xml definition
-Something.wizard.xml = wizard xml definition
-Something.calendar.xml = calendar xml definition
-Something.email.xml = email xml definition
-Something.fax.xml = fax xml definition
-Something.pdf.xml = pdf xml definition
-Something.role.xml = role xml definition
-SomeValidator.php = 'Validator' means this file will be placed in
binarycloud/mgr/validators from a module directory.
-SomeProcessor = 'Processor' means this file will be placed in
binarycloud/mgr/processors from a module directory
-Something.xml.php = this file will be processed from xml to php using
default xml2php rules and written out in the same location in the build tree
with the extension .php.
-Something.lang.xml will be used by LangKeyer at make-time to key in
nagive-language strings into source files.
-Something.lang_code.php (i.e. Something.de.php or Something.en.php) means
the file will replace Something.php in same directory when the language code
is the same as lang_code. Useful for writing the same module that does
different things based on the location/language.
|
|
From: Alex B. <en...@tu...> - 2001-08-22 19:55:24
|
>> Respective for the XML complement. So QueryManager can loop over
>> the indexed arrays and generate an asoc array like:
>>
>> $buffer[rownumber] = array(
>> "Name1" => Datafromverlongcolumn1,
>> "Name" => Datafromverylongcolumn2
>> );
>
> Forgot to mention this. Using this method makes fetching result metadata
> obsolete. That would reduce db load and saving time, I guess.
>
> But the main point is to get around truncation.
Right, but isn't that a lot of work for not much benefit? And where to we
store the metadata, in the Entity definition?
<field>
<name>LongMixedCaseFieldNameWithNoStandard</name>
<short_name>LONGMIXED</short_name>
</field>
egh! :)
---
I rethought an earlier message, so:
-I don't want QueryManager to 'enforce' any field naming or other
standards. I don't want enforcement anywhere in the system.
-What I would like to enforce with scripts, etc is this:
:: For modules to be distributed with binarycloud or available from the
(upcoming) module repository, you must:
-Use field and table/entity names with less than 32 chars.
-Use CAPS for all field and table/entity names.
-Verify that your SQL & Schemas work with Oracle, MySQL, and
PostgreSQL.
Does that sounds reasonable to everyone?
_a
|
|
From: Alex B. <en...@tu...> - 2001-08-22 19:34:25
|
> Hi Alex,
>
>>> So we should use indexed array for the result retrieving only.
>>> I'm not surehow this will fit with EntityManager (I briefly looked over
> the
>>> code and saw that by doing queries the $headers switch is turned on) but
> if it > > really needs that a mapping could be done in EntityManager not in
>>> QueryManager.
>> I would almost prefer to standardize db field names rather than
>> avoid using array keys, which are helpful for coding and debugging.
> Thats another option if the portability is guaranteed (nothing is
> truncated).
> But what if the db system changes its behaviour in a new versions?
> Everything has to be fixed. For debugging and code readability it's nice.
My point is that if we establish fairly restrictive standards about table
and field naming, we can get around those problems and ensure compatibility
between oracle, mySQL, and Postgres:
-table names * field names no longer than 32 chars
-all field and table names in CAPS
for example.
> Another option to get around this at QueryManager level could be an
> additional option field within the query statement e.g.:
>
> $query = array(
> 'QUERY' =>
> "SELECT VeryLongColumThatMightBeTruncated, ".
> "anotherVeryLongColThatIsDefenetlyTruncated ".
> "FROM tablewithverylongfieldnames WHERE foo = ?",
> 'ARGTYPES' => array('integer'),
> 'FIELDNAMES' => array('Name1','Nam2');
> );
>
> Respective for the XML complement. So QueryManager can loop over the indexed
> arrays and generate an asoc array like:
>
> $buffer[rownumber] = array(
> "Name1" => Datafromverlongcolumn1,
> "Name" => Datafromverylongcolumn2
> );
>
> So we do not have the truncation problem but maybe a bit less performance
> and a bit more typing in this mode of operation.
>
> Additionally we should do a naming convetion for tables/fields. Then we are
> 100%save ;-)
Re: the above, I'd prefer to have something that works with a standard,
instead of trying to build code that works with 'everything'.
I'm not saying QueryManager should process incoming queries (like
strtoupper) but I think we should standardize those names elsewhere in the
system.
_a
>
>>> STORED QUERIES:
>>> QueryManager does have the abiliy to load stored queries. This
>> is used in
>>> EntityManager to load queries related to entities. But there
>> might be the
>>> need to load user queries for one page call. My proposal is to
>> use the query
>>> load system on init, optionally of course. So we could have a
>> syntax like
>>> this
>>>
>>> <database>
>>> <mcrypt>true</mrypt>
>>> ..
>>> <queries>
>>> <query>user.db.qry.UserQueriesFoo</query>
>>> <query>user.db.qry.UserQueryBar</query>
>>> </queries>
>>>
>>> On Init the file user.db.qry.UserQueriesFoo is importet and the
>> queries are
>>> added to the queryList. The user then does have the abiliy to
>> execute his
>>> querys directly: qm->DoQuery("QRY_USER_MYQUERYNAME").
>>
>
>> Why here? (I.e. in init, so early) why shouldn't query loading be the
>> responsibility of the code that needs the query?
> Hmm. If I have a page and I want to load a set of queries that are used by
> some or all modules of this page. I load the query-set at init time and the
> modules do not have to care about query loading. On the other hand the
> module could load the query passed by a parameter "user.mod.foo.Queries".
> Hmmm....
>
> [query xml format]
>> I like the format above, nice n' clean :)
> Jepp. I think I'll do some experiments with that. And also with the query
> loading stuff.
>
> Andi
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>
|
|
From: Andreas A. <a.a...@th...> - 2001-08-22 19:24:32
|
Re, > Respective for the XML complement. So QueryManager can loop over > the indexed arrays and generate an asoc array like: > > $buffer[rownumber] = array( > "Name1" => Datafromverlongcolumn1, > "Name" => Datafromverylongcolumn2 > ); Forgot to mention this. Using this method makes fetching result metadata obsolete. That would reduce db load and saving time, I guess. But the main point is to get around truncation. Andi |
|
From: Alex B. <en...@tu...> - 2001-08-22 19:12:00
|
> No I can't think of a case where they would be needed either, though I > noticed the support for attribues in XMLUtils.php, so I assumed it would > parse them as well. Oh really? Cool. Well, if we decide we need attributes, we can use 'em easily :) _a |
|
From: Andreas A. <a.a...@th...> - 2001-08-22 19:07:52
|
Hi Alex,
> > So we should use indexed array for the result retrieving only.
> > I'm not surehow this will fit with EntityManager (I briefly looked over
the
> > code and saw that by doing queries the $headers switch is turned on) but
if it > > really needs that a mapping could be done in EntityManager not in
> > QueryManager.
> I would almost prefer to standardize db field names rather than
> avoid using array keys, which are helpful for coding and debugging.
Thats another option if the portability is guaranteed (nothing is
truncated).
But what if the db system changes its behaviour in a new versions?
Everything has to be fixed. For debugging and code readability it's nice.
Another option to get around this at QueryManager level could be an
additional option field within the query statement e.g.:
$query = array(
'QUERY' =>
"SELECT VeryLongColumThatMightBeTruncated, ".
"anotherVeryLongColThatIsDefenetlyTruncated ".
"FROM tablewithverylongfieldnames WHERE foo = ?",
'ARGTYPES' => array('integer'),
'FIELDNAMES' => array('Name1','Nam2');
);
Respective for the XML complement. So QueryManager can loop over the indexed
arrays and generate an asoc array like:
$buffer[rownumber] = array(
"Name1" => Datafromverlongcolumn1,
"Name" => Datafromverylongcolumn2
);
So we do not have the truncation problem but maybe a bit less performance
and a bit more typing in this mode of operation.
Additionally we should do a naming convetion for tables/fields. Then we are
100%save ;-)
> > STORED QUERIES:
> > QueryManager does have the abiliy to load stored queries. This
> is used in
> > EntityManager to load queries related to entities. But there
> might be the
> > need to load user queries for one page call. My proposal is to
> use the query
> > load system on init, optionally of course. So we could have a
> syntax like
> > this
> >
> > <database>
> > <mcrypt>true</mrypt>
> > ..
> > <queries>
> > <query>user.db.qry.UserQueriesFoo</query>
> > <query>user.db.qry.UserQueryBar</query>
> > </queries>
> >
> > On Init the file user.db.qry.UserQueriesFoo is importet and the
> queries are
> > added to the queryList. The user then does have the abiliy to
> execute his
> > querys directly: qm->DoQuery("QRY_USER_MYQUERYNAME").
>
> Why here? (I.e. in init, so early) why shouldn't query loading be the
> responsibility of the code that needs the query?
Hmm. If I have a page and I want to load a set of queries that are used by
some or all modules of this page. I load the query-set at init time and the
modules do not have to care about query loading. On the other hand the
module could load the query passed by a parameter "user.mod.foo.Queries".
Hmmm....
[query xml format]
> I like the format above, nice n' clean :)
Jepp. I think I'll do some experiments with that. And also with the query
loading stuff.
Andi
|
|
From: Jason H. <jc...@ey...> - 2001-08-22 19:04:28
|
No I can't think of a case where they would be needed either, though I noticed the support for attribues in XMLUtils.php, so I assumed it would parse them as well. just curious Alex Black wrote: > > What about attributes? > > <element1 this="that" foo="bar">value</element1> > > > > Will they be supported in xml2php? > > Not at the moment. |
5 messages has been excluded from this view by a project administrator.
