binarycloud-dev — development list for binarycloud

RE: [binarycloud-dev] Future source tree:

[Andreas A. <a.a...@th...>]

Hi Alex,

> 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

What do you think about naming the xml.php files in sync with the above?

Something.php.xml

This would fit better name.whatitbecomes.filetype

Andi

RE: [binarycloud-dev] XML2PHP supplemental

[Andreas A. <a.a...@th...>]

Hi Andris,

[cvs]
> Yup. The server said: cvs [server aborted]: "commit" requires write
> access to the repository...
Hmm.. Did you set up the SSH stuff correctly? You can also use pserver with
sourceforge but thats readonly.

You're using windows right? There is a setup tool for sourceforge to set
everything up in windows + wincvs.

Try the following:

ssh -l usersfaccount cvs.binarycloud.sourceforge.net

type in your password

Does this work?

Important to cvs is, to have CVS recognize the ssh method.
export CVS_RSH=ssh (bash)

If you're under cygwin the ssh for cygwin does not work with wincvs.


> > xml2php should look for BC_* and act accordingly i.e. BC_PATH."path/to/"
> The latest XMLUtils does just that.
Cool. Alex, did you do a sync ?

> > Another problem ist that xml2php translates structures with no more than
> > one"entry" like:
>  Not sure I understand what you mean, but with latest XMLUtils
> & xml2php
> and the xml file definitions I sent to Alex, the only thing one needs to
> change is passwords in datasources.php. After that, even the query_example
> works.

So does it work if you have more than one entry in your datasources.xml.php?

With only _one_ record in the source xml.php file:

<datasources>
  <datasource>
    <name>value</includepath>
    <database>value</database>
  </datasource>
</datasources>

The generated php looks like:

$QueryManager->datasources = array(
  'datasources' => array(
        name => value,
        database => value
    ),
);

If I put another "datasource" to the xml.php file...

<datasources>
  <datasource>
    <name>value</includepath>
    <database>value</database>
  </datasource>
  <datasource>
    <name>value2</includepath>
    <database>value2</database>
  </datasource>
</datasources>

.. i get this:

$QueryManager->datasources = array(
    array(
        name => value,
        database => value
    ),
    array(
        name => value2,
        database => value2
    ),
...
);

And that's exactly what we have in langs.php and going to have in queries,
and to be in sync also with datasources (I've already modded querymanager to
support this and will commit if everything works fine with your latest xml
stuff).

So xml2php behaves right if at least 2 datasources, langs, queries etc are
defined.

Andi

[binarycloud-dev] test ignore

[John P. C. <jca...@in...>]

I have had trouble with my responses showing up.  This
is a test.

RE: [binarycloud-dev] Re: xml2php is working (woohoO!)

[Andreas A. <a.a...@th...>]

Hi Andris,

> > The line $argv = $HTTP_SERVER_VARS["argv"]; should work only 
> > when the php file is executed by Apache?

No, it's executed on the command line. No Webserver interaction.

argv is just the parameter list:

script.php one two three ..
[0] = script.php
[1] = one
[2] = three
...

Andi

[binarycloud-dev] XML2PHP supplemental

[Andris S. <an...@do...>]

> > I'll try to commit the latest version of it all tomorrow (I'm going to
> > figure out how to commit something at all as the day before
> > yesterday was my first day with CVS).
>Cool. I'll help if you have probs.
    Yup. The server said: cvs [server aborted]: "commit" requires write
access to
the repository...

>prepend.php is replicated over all dirctories, i guess.
    Alex, what do u think?

> In fact it does not work with quotes. That's a problem. I just worked
around
> it by setting IncludePath directly in QueryManager. But I don't like it.
So
> xml2php should look for BC_* and act accordingly i.e. BC_PATH."path/to/"
    The latest XMLUtils does just that.

> Another problem ist that xml2php translates structures with no more than
one
> "entry" like:
    Not sure I understand what you mean, but with latest XMLUtils & xml2php
and the xml file definitions I sent to Alex, the only thing one needs to
change is passwords in datasources.php. After that, even the query_example
works.

Andris Spruds

Re: [binarycloud-dev] QueryManager / Standards

[Ronald T. <ron...@ho...>]

> > For modules to be distributed with binarycloud or available from the
> > (upcoming) module repository, as well as for binarycloud core components
> > you must:
> > - Use field and table/entity names with less than 32 chars
> > - Use lowercase for all database, field and table/entity names
> > - Use CAPS for SQL command (SELECT, AS, FROM, DELETE...)
> > - Verify that your SQL & Schemas work with Oracle, MySQL, and 
>PostgreSQL.
>
>deal.
>
>anyone else have comments/etc?
>
>I'm preparing a significant revision on the binarycloud coding standards...
>this will make it in.
>
>best,
>
>_alex
>
Cool!!
I used the about kind of standard on my own for a long long time...
it really makes life easier......
I will be very happy BC will maintain this standard...

roni

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

RE: [binarycloud-dev] XML2PHP supplemental

[Andreas A. <a.a...@th...>]

Hi Andris,

> > include_once('./prepend.php');
> > is also missing for the generated pagedef

> I'll try to commit the latest version of it all tomorrow (I'm going to
> figure out how to commit something at all as the day before
> yesterday was my first day with CVS).
Cool. I'll help if you have probs.

> About "prepend'" , I wonder whether it works if we have
> a file,lets say, in /htdocs/mydircteory/something/file.php?
prepend.php is replicated over all dirctories, i guess.

> And more: how can we know if we want our value to be quoted? I mean,
> sometimes something like this BC_PATH."/ext/metabase" is passed and it
> doesn't need usual quotes arround it....
In fact it does not work with quotes. That's a problem. I just worked around
it by setting IncludePath directly in QueryManager. But I don't like it. So
xml2php should look for BC_* and act accordingly i.e. BC_PATH."path/to/"

Another problem ist that xml2php translates structures with no more than one
"entry" like:

<langs>
  <lang>
   ...
  </lang>
</langs>

into

$data = array(
    'lang'= array (..);
);

but what we want is

$data = array(
    array(
	...
    )
);

For the moment this was only a problem with datasources.php and i added a
dummy entry to avoid this.


Best,

Andi

[binarycloud-dev] Re: xml2php is working (woohoO!)

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

hi all,

(and of course, Andris)

I have just used andris' latest zip to do a successful make, which seems to
be working fine.

I'm going to check in now, even if there's a couple minor problems I don't
care because this works! cool!

:)

-alex

> I had problems commiting (cvs said [server aborted]: "commit" requires write
> access to the repository), so I'm sending zip with the files. Hopefully I
> haven't forgotten anything this time.
> 
> The line $argv = $HTTP_SERVER_VARS["argv"]; should work only when the php
> file is executed by Apache?
> 
> Andris Spruds
> 
> 
> 
> 

[binarycloud-dev] XML2PHP supplemental

[Andris S. <an...@do...>]

> Andris,
>
> include_once('./prepend.php');
>
> is also missing for the generated pagedef
>
> Andi

I'll try to commit the latest version of it all tomorrow (I'm going to
figure out how to commit something at all as the day before yesterday was my
first day with CVS). About "prepend'" , I wonder whether it works if we have
a file,lets say, in /htdocs/mydircteory/something/file.php?

And more: how can we know if we want our value to be quoted? I mean,
sometimes something like this BC_PATH."/ext/metabase" is passed and it
doesn't need usual quotes arround it....

Andris Spruds

Re: [binarycloud-dev] QueryManager / Standards

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

agreed.

-a

> Hi Alex,
> 
> 
>> it _looks_ like oracle returns them in uppercase, but I haven't checked
>> QueryManager for strtoupper().
> 
> Ok if so, we should add strtolower() in process results.
> 
> 
> Andi
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] Implementing version control/history

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

> 
> An interesting problem becomes maintaining some mechanism of storing
> unique ids which are not the primary key of a given entity table and are
> not unique.  After some high level thinking on the subject, we had
> decided to store all unique object identifiers, let's call them OID for
> short, or, keeping with bc nomenclature, EID, in a separate table from
> which any new entity creation process would request and receive a new
> EID before inserting a new entity into it's entity table.

That's interesting. In which case you _could_ just use a normal entity, and
have the actual data entity separate.

> The EID table would store the EID and the entity table.  Adding columns
> to this table allows very cool things such as locking entities (set a
> flag in the central EID table), check-in and check-out of entities, etc.

Yeah. heh. CVS in oracle!

> This versioning business will also have significant impact on the fields
> of type "pointer".  I.e. if the referred entity type is versioned, do
> you store the EID, or the actual ID from the entity's table (in order to
> point to a particular version of the entity as opposed to always
> pointing to the latest).  This, perhaps, needs to be configurable as
> well.  Using the furbee_type_id field from entity_new.xml, let's say
> that furbee_types are versioned - because Furbees, Inc. routinely
> changes type definitions, and a given instance of a furbee's type should
> never change.  In this case, we want to always point to the same version
> of the type.
> 
> [ *snip* ]
> <field>
>           <name>furbee_type_id</name>
>           <label>Furbee type ID</label>
>           <desc>The id of the type of furbee</desc>
>           <path>furbee_type_id</path>
>           <required>true</required>
>           <type>
>               <dbtype>int</dbtype>
>               <!--
>               note the "pointer" type
>               this field is a pointer to another entity, and a
>               foreign key in the database.
>               -->
>               <type>versioned_pointer</type>
>    <!--
> If we had parameters in the XML definition, we could do
> something like:
> <type param="versioned">pointer</type> - to keep from
> creating too many
> like types which have only minor variations.
>    -->
>               <!--
>               form above, the entity name to use for requesting
>               data from this pointer
>               -->
>               <entity>furbee_type</entity>
>               <maxlength>20</maxlength>
>               <format>/[\w\s_\-\.]{0,20}/</format>
>           </type>
> </field>
> [ *snip* ]

yes, though I think I'd want to have that "versioned" flag be part of the
top-level entity definition.

...

_a

Re: [binarycloud-dev] QueryManager / Standards

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

>>> 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?
> 
>> 2)
>> I don't like it because I think it's a hell of a lof more elegant to have
>> 'name sync' between entities, entity paths, and sql.
> 
> I'm with you. If we establish a standard like proposed, we must keep it
> throughout the system. It makes live lot easier.

Agreed.

I don't want to put in any code that necessarily enforces the standard, but
I want to document and adhere to it.

>>> be nice. E.g. "FurbeeId" is more readable than "furbeeid" or "FURBEEID".
>> The above is opinion, not doctrine... does anyone else have an opinion on
>> this one?
> Personally I like the furbeeId, userId, furbeeName syntax.  But with the
> compatibility issues and the complexity of the system in mind  it might be
> really wired in large applications. Its easier to track the path from a
> entity to the database if everything is in sync.

actually, I agree: I prefer MooId or mooId, etc. But I think if we have to
go with 'single case' the best is lowercase field_name

> Additionally I prefer do add the strtolower() thing in buffer creation ( as
> originally done with strotupper() ). So users have the freedom to name the
> database fields mixed case (FurbeeId) but the system gets them as all
> lowercase (furbeeid). But for the repository modules it should stay as
> proposed.

hmm. that is enforcing policy, but I think I'm willing to break my statement
above and say "yeah" :)

> Note to the query syntax: As I said before I like to write queris with SQL
> statements UPPERCASE. I'd love to add this to the standard 'caus it make the
> queries MUCH more readable.

yes, ditto.

> So from my point of view I think the following is very acceptable:
> 
> For modules to be distributed with binarycloud or available from the
> (upcoming) module repository, as well as for binarycloud core components
> you must:
> - Use field and table/entity names with less than 32 chars
> - Use lowercase for all database, field and table/entity names
> - Use CAPS for SQL command (SELECT, AS, FROM, DELETE...)
> - Verify that your SQL & Schemas work with Oracle, MySQL, and PostgreSQL.

deal.

anyone else have comments/etc?

I'm preparing a significant revision on the binarycloud coding standards...
this will make it in.

best,

_alex

RE: [binarycloud-dev] QueryManager / Standards

[Andreas A. <a.a...@th...>]

Hi Alex,


> it _looks_ like oracle returns them in uppercase, but I haven't checked
> QueryManager for strtoupper().

Ok if so, we should add strtolower() in process results.


Andi

[binarycloud-dev] XML2PHP supplemental

[Andreas A. <a.a...@th...>]

Andris,

include_once('./prepend.php'); 

is also missing for the generated pagedef

Andi

RE: [binarycloud-dev] QueryManager / Standards

[Andreas A. <a.a...@th...>]

Hi,

> > 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?

> 2)
> I don't like it because I think it's a hell of a lof more elegant to have
> 'name sync' between entities, entity paths, and sql.

I'm with you. If we establish a standard like proposed, we must keep it
throughout the system. It makes live lot easier.

> > be nice. E.g. "FurbeeId" is more readable than "furbeeid" or "FURBEEID".
> The above is opinion, not doctrine... does anyone else have an opinion on
> this one?
Personally I like the furbeeId, userId, furbeeName syntax.  But with the
compatibility issues and the complexity of the system in mind  it might be
really wired in large applications. Its easier to track the path from a
entity to the database if everything is in sync.

Additionally I prefer do add the strtolower() thing in buffer creation ( as
originally done with strotupper() ). So users have the freedom to name the
database fields mixed case (FurbeeId) but the system gets them as all
lowercase (furbeeid). But for the repository modules it should stay as
proposed.

Note to the query syntax: As I said before I like to write queris with SQL
statements UPPERCASE. I'd love to add this to the standard 'caus it make the
queries MUCH more readable.

So from my point of view I think the following is very acceptable:

For modules to be distributed with binarycloud or available from the
(upcoming) module repository, as well as for binarycloud core components
you must:
- Use field and table/entity names with less than 32 chars
- Use lowercase for all database, field and table/entity names
- Use CAPS for SQL command (SELECT, AS, FROM, DELETE...)
- Verify that your SQL & Schemas work with Oracle, MySQL, and PostgreSQL.


Andi

RE: [binarycloud-dev] Implementing version control/history

[Alok K. D. <al...@dh...>]

An interesting problem becomes maintaining some mechanism of storing
unique ids which are not the primary key of a given entity table and are
not unique.  After some high level thinking on the subject, we had
decided to store all unique object identifiers, let's call them OID for
short, or, keeping with bc nomenclature, EID, in a separate table from
which any new entity creation process would request and receive a new
EID before inserting a new entity into it's entity table.

The EID table would store the EID and the entity table.  Adding columns
to this table allows very cool things such as locking entities (set a
flag in the central EID table), check-in and check-out of entities, etc.

This versioning business will also have significant impact on the fields
of type "pointer".  I.e. if the referred entity type is versioned, do
you store the EID, or the actual ID from the entity's table (in order to
point to a particular version of the entity as opposed to always
pointing to the latest).  This, perhaps, needs to be configurable as
well.  Using the furbee_type_id field from entity_new.xml, let's say
that furbee_types are versioned - because Furbees, Inc. routinely
changes type definitions, and a given instance of a furbee's type should
never change.  In this case, we want to always point to the same version
of the type.

[ *snip* ]
<field>
            <name>furbee_type_id</name>
            <label>Furbee type ID</label>
            <desc>The id of the type of furbee</desc>
            <path>furbee_type_id</path>
            <required>true</required>
            <type>
                <dbtype>int</dbtype>
                <!--
                note the "pointer" type
                this field is a pointer to another entity, and a
                foreign key in the database.  
                -->
                <type>versioned_pointer</type>
	    <!--
		If we had parameters in the XML definition, we could do
something like:
		<type param="versioned">pointer</type> - to keep from
creating too many
	  	like types which have only minor variations.
	    -->
                <!--
                form above, the entity name to use for requesting
                data from this pointer
                -->
                <entity>furbee_type</entity>
                <maxlength>20</maxlength>
                <format>/[\w\s_\-\.]{0,20}/</format>
            </type>
</field>
[ *snip* ]

Cool stuff.

Al

> -----Original Message-----
> From: bin...@li... 
> [mailto:bin...@li...] On 
> Behalf Of Alex Black
> Sent: Thursday, August 23, 2001 1:33 PM
> To: binarycloud-dev
> Subject: Re: [binarycloud-dev] Implementing version control/history
> 
> 
> > 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.
> 
> Heh, cool.
> 
> Ah, i.e. you're implementing this on an "individual" 
> entityManager basis.
> 
> I'd prefer to add it as a system level extension to the 
> EntityManager, do you agree?
> 
> 
> >> 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
> 
> I think so:
> 
> so where one normally would request an entity record id, 
> like: "give me address id 254" you could change the bahavior 
> of Get etc to say "give me address id 245 timestamp latest" 
> or "give me address id 254 city berkeley"
> 
> I think you'd want to implement it as john suggests: 
> VersionedEntityManager, which would override some base methods.
> 
> hmm...
> 
> _a
> 
> 
> _______________________________________________
> binarycloud-dev mailing list bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] make errors with xml2php

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

> Hi Andris.
> 
>> 2) whether you have enabled register_argc_argv and
>> register_globals in your php.ini file.
> OK. That was the problem.
> 
> Fantastic. It works!!
> 

andreas: can you commit it?

or andris?

if it works, I want it :) gimme gimme! heh


> 1) to get arount the register_global/arg stuff you can put this into the
> xml2php
> ini_set('register_globals', on);
> $argv = $HTTP_SERVER_VARS["argv"];

yes, we should set that in all of the command line scripts.
then again, we _could_ integrate that into Init::_ini_set with some sort of
constant flag like

define("HEY_IM_ON_THE_COMMAND_LINE_HERE", true); :)

> 2) The output for datasources is not quite correct. (see. Lang)
> 
> global $QueryManager;
> $QueryManager->datasources = array(...)
> 
> Uuups. I think i have to change init/qm as well to support the same format
> as in Lang.

cool.


> datasources(
> array(data),
> array(data)
> );
> 
> 
> currently:
> datasources(
> 'hook' => array(data),
> 'hook2' => array(data)
> );
> 
> 3) We should find a way to have a the interpreter line in the php files more
> flexible through the different platforms. Perl has a trick to do so
> eval 'exec perl -S $0 "$@"'
> Maybe we find a way to handle that better.

agreed, I was going to suggest a simple ./configure.sh which would do a grep
for a php command line key.

any other ideas?

_a

RE: [binarycloud-dev] make errors with xml2php

[Andreas A. <a.a...@th...>]

Hi Andris.

> 2) whether you have enabled register_argc_argv and
> register_globals in your php.ini file.
OK. That was the problem.

Fantastic. It works!!

Some notes:

1) to get arount the register_global/arg stuff you can put this into the
xml2php
ini_set('register_globals', on);
$argv = $HTTP_SERVER_VARS["argv"];


2) The output for datasources is not quite correct. (see. Lang)

global $QueryManager;
$QueryManager->datasources = array(...)

Uuups. I think i have to change init/qm as well to support the same format
as in Lang.

datasources(
	array(data),
	array(data)
);


currently:
datasources(
	'hook' => array(data),
	'hook2' => array(data)
);

3) We should find a way to have a the interpreter line in the php files more
flexible through the different platforms. Perl has a trick to do so
eval 'exec perl -S $0 "$@"'
Maybe we find a way to handle that better.

Andi

Re: [binarycloud-dev] Implementing version control/history

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

> 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.

Heh, cool.

Ah, i.e. you're implementing this on an "individual" entityManager basis.

I'd prefer to add it as a system level extension to the EntityManager, do
you agree?


>> 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

I think so:

so where one normally would request an entity record id, like: "give me
address id 254" you could change the bahavior of Get etc to say "give me
address id 245 timestamp latest" or "give me address id 254 city berkeley"

I think you'd want to implement it as john suggests: VersionedEntityManager,
which would override some base methods.

hmm...

_a

Re: [binarycloud-dev] Implementing version control/history

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

> 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.

I see the problem and the 'former' post.

If you store like ids you need to be able to pass some other qualifier that
can pick out a unique record.

So, I think this should be in entitymanager - not 'version control' but
something general like 'the unique id on this entity is composed of more
than 2 fields'

it does introduce the potential for complexity, but I see the need and it
makes sense.


> 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.

Correct. I do suggest that we work together to design it into the system,
however.

> 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?

I agree, let's do it.

_a

I'll also respond to JPC, his opinion being the more relevant on here.


> Thanks.
> 
> Al

Re: [binarycloud-dev] cygwin modules

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

I've worked it out... just a second.

Complete Cygwin package list:
----------------------------------------------------------------------------
---
Autoconf
Automake
Bash
Binutils
Clear
Cygwin (both packages)
Diff
File
Fileutils
Findutils
Grep
gZip
Inetutils
Less
Lynx
Make
Perl
Readline
Reges
Rsync
Sed
Sh-Utils
Tar
Textutils
Time
Unzip
w32API
wGet
Which
---------
Download is roughly 7.7MB.


I just commited this into INSTALL.WIN32.

_a

> 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.
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] Query definition format

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

looks great.

:)

-a

> 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
> 

Re: [binarycloud-dev] QueryManager / Standards

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

> 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?

1)
yes that is entirely possible

2)
I don't like it because I think it's a hell of a lof more elegant to have
'name sync' between entities, entity paths, and sql.

> 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 :-)

The above is opinion, not doctrine... does anyone else have an opinion on
this one?

_a




> --
>        * *       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
> 
> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] QueryManager / Standards

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

> 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.

it _looks_ like oracle returns them in uppercase, but I haven't checked
QueryManager for strtoupper().

_a

Re: [binarycloud-dev] Future source tree:

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

> 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.

I was thinking that, and yes I agree.

I'll send an amended list to the list (err)
 
>> 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?

nonono,

we'll have separate subdirectories for each image tree re: a module - but
the above does apply to Validators, etc.

>> -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 ?

yes, it will work for any file extension, and I should mention that. good
point #2 :)

>> -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
> ...

Same :)

_a