vcl4php-developers — Mailing list for contributors to the framework

Re: [vcl4php-developers] Having the VCL do some checking

[Gary <z0...@40...>]

Yes, mine looks like: file:///c:/program files/codegear
I use XAMPP for Windows which is apache so it doesn't have the problem. And
we currently don't have php installed on our server 2003's. 

Re: [vcl4php-developers] Having the VCL do some checking

[José L. <su...@qa...>]

Gary escribió:
> I see no reason why it couldn't, probably easier than in the ide.
> 
> I don't know how all servers work but I think the drive letter problem only
> occurs when running in the ide as the rest all start from htmlroots? 
> 
> Perhaps the first check would be if the url contains localhost - or perhaps
> just the port # that would mean it was running in the ide just to save
> needless processing on the remote servers.
Running from the IDE, the http_path defined in the vcl.inc.php always 
contain file://, so these simple lines do the trick.

         if (strpos($http_path,'file://')===false)
         {
           //everything is ok, script and vcl are in the same drive
         }
         else
         {
           trigger_error('VCL for PHP resides in a different drive than 
your script, this cause security problems with assets when requested by 
the browser, please, save your project in the same drive.', E_USER_NOTICE);
         }

It generates a notice, to allow the script be executed, as simple PHP 
files doesn't have problems running on a different drive. If the user 
wants to run the script, can tweak the error reporting to a higher level.

Still need to check running scripts on a windows server on different drives.

What do you think?

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

Re: [vcl4php-developers] Having the VCL do some checking

[Gary <z0...@40...>]

I see no reason why it couldn't, probably easier than in the ide.

I don't know how all servers work but I think the drive letter problem only
occurs when running in the ide as the rest all start from htmlroots? 

Perhaps the first check would be if the url contains localhost - or perhaps
just the port # that would mean it was running in the ide just to save
needless processing on the remote servers.

On Thu, 18 Dec 2008 13:46:18 +0100, José León <su...@qa...> wrote:
> Gary escribió:
>> I just logged a qc suggestion on this earlier today but I got to
> thinking
>> about some others.
>>
>> I'm always helping someone out with having the ide and project on
> different
>> drives, so I suggested that the ide complain about it when it was run.
>>
>> That got me to thinking that maybe the VCL should throw an exception, if
>> for instance, it was asked to write out an ajaxCall but use ajax is not
> set
>> to true in the form.
>>
>> Perhaps there are other things like that also. Can anyone think of any
>> more?
> If the script is on a different drive the VCL, then, on vcl.inc.php, the
> HTTP paths that are generated will contain drive letters, we could
> include a check on this, so even the IDE won't need to be modified. What
> do you think?
> 
> Regards
> --
> José León
> qadram software
> C/Juan Ramón Jiménez, 15 Entlo. 2
> 03203 Elche ALICANTE (SPAIN)
> T: +34 965 45 48 48
> F: +34 965 45 48 48
> M: +34 618 28 13 69
> http://www.qadram.com

Re: [vcl4php-developers] Having the VCL do some checking

[José L. <su...@qa...>]

Gary escribió:
> I just logged a qc suggestion on this earlier today but I got to thinking
> about some others.
> 
> I'm always helping someone out with having the ide and project on different
> drives, so I suggested that the ide complain about it when it was run.
> 
> That got me to thinking that maybe the VCL should throw an exception, if
> for instance, it was asked to write out an ajaxCall but use ajax is not set
> to true in the form.
> 
> Perhaps there are other things like that also. Can anyone think of any
> more?
If the script is on a different drive the VCL, then, on vcl.inc.php, the 
HTTP paths that are generated will contain drive letters, we could 
include a check on this, so even the IDE won't need to be modified. What 
do you think?

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

[vcl4php-developers] Having the VCL do some checking

[Gary <z0...@40...>]

I just logged a qc suggestion on this earlier today but I got to thinking
about some others.

I'm always helping someone out with having the ide and project on different
drives, so I suggested that the ide complain about it when it was run.

That got me to thinking that maybe the VCL should throw an exception, if
for instance, it was asked to write out an ajaxCall but use ajax is not set
to true in the form.

Perhaps there are other things like that also. Can anyone think of any
more?

Re: [vcl4php-developers] Proposed additions to common.js

[Gary <z0...@40...>]

In my playing around with this I found that some users, for whatever
reason, don't get the update to common.js and work out of the cache. (2 of
30 so far)

As this isn't a good thing I got to thinking about forcing the refresh and
having the ability to include my own common scripts if I wanted to. See if
any of you like this idea or have a better suggestion.

In function dumpHeaderJavascript of forms.inc.php something like this:
================
                if (!defined('COMMON_JS'))
                {   
+                  if
(include_once(VCL_FS_PATH."/js/modifycommon.inc.php"))
+                    {
+                  $sp="<script type=\"text/javascript\"
src=\"".VCL_HTTP_PATH."/js/".$common."\"></script>\n";
+                  if ($mycommon != '') $sp.="<script
type=\"text/javascript\"
src=\"".VCL_HTTP_PATH."/js/".$mycommon."\"></script>\n";
+                    }
+                  else
+                    {  
                  $sp="<script type=\"text/javascript\"
src=\"".VCL_HTTP_PATH."/js/common.js\"></script>\n";
+                    }
                  define('COMMON_JS',1);
                }
================
Where modifycommon.inc.php contains
$common='common.js';
$mycommon='my_files_name.js';

Now if I make changes to my files I can change the names easily which will
force the clients to download a new script and as a bonus allows me to
include my own favorite javascripts without needing to add them to
common.js

What say you? Anybody home? :)

BTW this is where I'm at on my additions right now:
usage:
               editArray=vcl.$('edit1','edit2','edit3','edit4');
               vcl.$('Edit1').focus();
               vcl.setOpacity('Button1',5);
               alert(vcl.text('Button1'));
               vcl.hide('Button1');

===========common.js===========

vcl=
{
$:function ()
  {
  var elements = new Array();
  for (var i = 0; i < arguments.length; i++)
    {
    var element = arguments[i];
    if (typeof element == 'string')
            element = findObj(element);
    if (arguments.length == 1)
            return element;
    elements.push(element);
    }

  return elements;
  },
int:function(obj){ return parseInt(vcl.$(obj).value);},
real:function(obj){ return parseFloat(vcl.$(obj).value);},
escape:function(obj){ return escape(vcl.$(obj).value);},
unescape:function(obj){ return unescape(vcl.$(obj).value);},
focus:function(obj){ vcl.$(obj).focus();},
check:function(obj){ vcl.$(obj).checked=true;},
uncheck:function(obj){ vcl.$(obj).checked=false;},
hide:function(obj){ vcl.$(obj).style.display = 'none';},
show:function(obj){ vcl.$(obj).style.display = '';},
find:function(obj){ return vcl.$(obj);},
text:function(obj){ return vcl.$(obj).value;},
value:function(obj){ return vcl.$(obj).value;},
setOpacity:function(incoming,value)
 {
 theObj=vcl.$(incoming);
 theObj.style.opacity = value/10;
 theObj.style.filter = 'alpha(opacity=' + value*10 + ')';
 }
}

function createHTTPrequest()
{ /* Firefox, Opera 8.0+, Safari */
  try {return new XMLHttpRequest();}
  catch (error) {}
   /* newer IE */
  try {return new ActiveXObject("Msxml2.XMLHTTP");}
  catch (error) {}
  /* older IE */
  try {return new ActiveXObject("Microsoft.XMLHTTP");}
  catch (error) {}
  throw new Error("Your browser does not have AJAX support!");
}
function basicAjax (url,parameters,callback)
{
xmlHttp=createHTTPrequest();
if (callback) {xmlHttp.onreadystatechange=callback;}
   else
   {
    xmlHttp.onreadystatechange=function()
       {
        if(xmlHttp.readyState==4)
          {
          if (xmlHttp.status == 200)
            {eval(xmlHttp.responseText);}
           else
            {alert("Sorry, received a server error =
"+xmlHttp.statusText);}
          }
       }
    }
xmlHttp.open("POST",url,true);
if (basicAjaxAsyncFalse===1) xmlHttp.open("POST",url,false); //this will
force a wait for return
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
xmlHttp.setRequestHeader("If-Modified-Since", "Fri, 31 Dec 1999 23:59:59
GMT");
xmlHttp.send(parameters);
}

[vcl4php-developers] vcl.inc.php

[Gary <z0...@40...>]

I know I'm kind of late to the party but I finally installed the 30 day
trial.

This is what I did to my deployed /vcl to have only one copy. Also I
remember a
suggestion for getting the path set for zend and I see it hasn't been done
yet. 
Instead of doing it in the component part I did mine here. This suggested
change
is done as a standard vcl.inc which would then be edited and put on the
server.

I named the root folder vcl_v2 as I still have v1 vcl on my server and
didn't
want to have any confusion. 



Proposed changes to vcl.inc.php

-         require_once("acl.inc.php");

        $scriptfilename='';

        if (isset($_SERVER['SCRIPT_FILENAME'])) $scriptfilename=
$_SERVER['SCRIPT_FILENAME'];
        else
        {
                        global $HTTP_SERVER_VARS;

                        $scriptfilename=$HTTP_SERVER_VARS["SCRIPT_NAME"];
        }

        //Defines the PATH where the VCL resides
       
$fs_path=relativePath(realpath(dirname(__FILE__)),dirname(realpath($scriptfilename)));
        $http_path=$fs_path;
+         /**
+          * Default to a root/vcl so only 1 copy needed per website.
+          *  To use: Uncomment the following 3 lines and
+          * also comment out require_once("acl.inc.php"); 
+          * and then just have this file in a vcl folder under your
application.
+          * *NOTICE* Please leave an unchanged version in the IDE VCL
+          *
+          */
+ 	   //   $fs_path=$_SERVER["DOCUMENT_ROOT"].'/vcl_v2';
+ 	   //   $http_path='http://'.$_SERVER["HTTP_HOST"].'/vcl_v2';
+          //   require_once($fs_path."/acl.inc.php");
+         require_once("acl.inc.php");
+         /**
+          * Add includes for components that need them
+          *
+          */
+         set_include_path(get_include_path() . PATH_SEPARATOR .
$fs_path."/Zend/framework/library");

[vcl4php-developers] track bar

[Gary <z0...@40...>]

I was helping someone out with the trackbar tonight and I found a couple of
on documented features that I think may need tweaked.

1) If you set the value of the slider in the code 
$this->TrackBar2->setPosition(70); the hidden field goes to the browser set
at 0 and doesn't change until something moves the slider thumb so it will
go back to the server as a zero. Seems like it should be set to x.

2) If you want to access javascript features it isn't obvious how to get
the object. It is named s when created and with 2 or more sliders on a page
they are all named s so you can only get at the last one created with
commands like s.setValue(5);

I would propose that the nameing convention be changed to something like
slider_TrackBar2 ($this->name) instead of the generic s

Re: [vcl4php-developers] Proposed additions to common.js

[Gary <z0...@40...>]

Ok so you didn't like toggle... Well that got me thinking and I think this
is an even better helper routine:

vcl=
{
hide:function(obj){ var el = findObj(obj);el.style.display = 'none';},
show:function(obj){ var el = findObj(obj);el.style.display = '';},
find:function(obj){ return findObj(obj);},
text:function(obj){ return findObj(obj).value;},
value:function(obj){ return findObj(obj).value;}
}

//usage
vcl.hide("Button1");
alert(vcl.find("Edit1").value);
vcl.show("Button1");
alert(vcl.text("Edit1"));

And I'm sure it could be expanded even more, and it should be easy to
understand for the users.

[vcl4php-developers] patches

[Jonathan B. <co...@jo...>]

Hi All,

I've just re-syncronized my VCL copy with the current HEAD revision, and I 
have the following patches that I'd like to submit for inclusion into the 
VCL.

classes.patch, contains:
- Performance fix for Persistent::serialize, caches method names, uses 
foreach instead of while/each, and uses instanceof instead of inheritsFrom.
- Performance fix for Component::readNamePath, replaces use of property 
names with direct class variable access, replaces use of className with 
get_class, removes unnecessary $result = '' assignment.

controls.patch, contains:
- Fix for Control::getJSWrapperFunction, clears the hiddenfield after the 
submit is sent to prevent subsequent bogus event firing. If needed, I can 
supply a demo project to show this issue.

dbtables.patch, contains:
- Performance fix for DBDataSet::MoveBy, uses the DB driver's built-in Move 
instead of manually scrolling through the rows one at a time. Greatly 
enhances performance when paging in a large dataset.

vcl.patch, contains:
- Fix for include path issue. Currently, if the VCL is located in a 
different drive to the project, the VCL uses file:/// to refer to the VCL 
directory, for both the VCL_FS_PATH and VCL_HTTP_PATH constants. This is 
unnecessary for VCL_FS_PATH as PHP can access files located on a different 
drive. Furthermore, using file:/// for require_once prevents APC from 
caching the included PHP file.

Don't hesitate to make any comments, suggestions, criticisms etc. :-)

Jon 

Re: [vcl4php-developers] Proposed additions to common.js

[Gary <z0...@40...>]

> Would be possible to redefine the $ only if it's not being used? 

I suspect that would just add to the confusion level - You can use $() in
all cases except...

Needs to be an "always works this way" kind of thing.

$G() $F() $S() are all easy to remember get find search/seek 
Qf() quick/qadram find

Re: [vcl4php-developers] Proposed additions to common.js

[qadram s. <su...@qa...>]

Gary escribió:
> How about $eek :) (seek)
;-)

Would be possible to redefine the $ only if it's not being used? Also, 
this article shows how is being used in mootools:

http://solutoire.com/2007/09/20/understanding-mootools-selectors-e-and-es/

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

Re: [vcl4php-developers] Proposed additions to common.js

[Gary <z0...@40...>]

> Here is my bet (don't know if it's possible):
> 
> $this
               function Button1JSClick($sender, $params)
               {

               ?>
               function $this(){alert('what do you know')}
                  $this();
               <?php

               }

It worked. Just for giggles I tried $this->(){} but it didn't like it and
the autocomplete took over anyway.

I just have to wonder if it wouldn't increase confusion levels for the
beginner. At the least they would tend to write it like $this->. Probably
the same confusion if it was this$ or thi$ ;)

How about $eek :) (seek)


> Well, if it's named toggle, if you use it with a checkbox will be:
> 
> toggle(checkbox)
> 
> And you won't expect will hide it or show it, my bets:
> 
> toggleVisibility()
> toggleVisible()
> 
> I know is long, but we can provide to helper methods:
> 
> hide()
> show()
> 
showHide()
display()
switch()
switchVis()
swVis()
switchV()
togVis()



> If common.js grows, we will add a step in the build process to compress 
> it to reduce the size and leave the original as development source.

Good idea!

Of course I also want to add:


function createHTTPrequest()
{ /* Firefox, Opera 8.0+, Safari */
  try {return new XMLHttpRequest();}
  catch (error) {}
   /* newer IE */
  try {return new ActiveXObject("Msxml2.XMLHTTP");}
  catch (error) {}
  /* older IE */
  try {return new ActiveXObject("Microsoft.XMLHTTP");}
  catch (error) {}
  throw new Error("Your browser does not have AJAX support!");
}
function basicAjax (url,parameters,callback)
{
xmlHttp=createHTTPrequest();
if (callback) {xmlHttp.onreadystatechange=callback;}
   else
   {
    xmlHttp.onreadystatechange=function()
       {
        if(xmlHttp.readyState==4)
          {
          if (xmlHttp.status == 200)
            {eval(xmlHttp.responseText);}
           else
            {alert("Sorry, received a server error =
"+xmlHttp.statusText);}
          }
       }
    }
xmlHttp.open("POST",url,true);
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
xmlHttp.setRequestHeader("If-Modified-Since", "Fri, 31 Dec 1999 23:59:59
GMT");
xmlHttp.send(parameters);
}

Re: [vcl4php-developers] Proposed additions to common.js

[qadram s. <su...@qa...>]

Gary escribió:
> I have a few routines that I would like to try and get included into the
> official script.
> 
> I would appreciate some help in naming a few of them - and maybe some
> support on the need to include them. :)
> 
> First one:
> I started off with it called $() but turns out that collides with namespace
> in qooxdoo so for now I changed it to $$ other thoughts I had are FO() for
> a takeoff on findObj and GET().  Any suggestions?
Here is my bet (don't know if it's possible):

$this


> function $$()
> {
> var elements = new Array();
> for (var i = 0; i < arguments.length; i++)
>     {
>     var element = arguments[i];
>     if (typeof element == 'string')
>             element = findObj(element);
>     if (arguments.length == 1)
>             return element;
>     elements.push(element);
>     }
> return elements;
> }
> 
> this is a replacement/enhancement for document.getElementById() and
> findObj()
> 
> alert($$('Edit1').value);//just get one object
> 
> IMO this is very cool in that it can also get an array of objects!!
> (includes obj we all ready had found also and real objects like
> LabeledEdit)
> 
> 
> var elements = $$('Edit2','Edit4','Edit6',obj1,obj2,'Edit5','Edit3');
> for (var i=0;i < elements.length; i++) elements[i].value='';
> //we just blew through a bunch of edits and cleared them.
> 
> The second one, toggle, is for html/css objects and just shows and hides
> them. Got a better name suggestion?
> 
> function toggle(obj)
> {
> var el = $$(obj);
> if ( el.style.display != 'none' )
>         {
>         el.style.display = 'none';
>         }
>  else
>         {
>         el.style.display = '';
>         }
> }
Well, if it's named toggle, if you use it with a checkbox will be:

toggle(checkbox)

And you won't expect will hide it or show it, my bets:

toggleVisibility()
toggleVisible()

I know is long, but we can provide to helper methods:

hide()
show()

If common.js grows, we will add a step in the build process to compress 
it to reduce the size and leave the original as development source.

Anyone is welcome to participate, as soon as Delphi for PHP Update 1 is 
released, we will start committing changes.

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

[vcl4php-developers] Proposed additions to common.js

[Gary <z0...@40...>]

I have a few routines that I would like to try and get included into the
official script.

I would appreciate some help in naming a few of them - and maybe some
support on the need to include them. :)

First one:
I started off with it called $() but turns out that collides with namespace
in qooxdoo so for now I changed it to $$ other thoughts I had are FO() for
a takeoff on findObj and GET().  Any suggestions?

function $$()
{
var elements = new Array();
for (var i = 0; i < arguments.length; i++)
    {
    var element = arguments[i];
    if (typeof element == 'string')
            element = findObj(element);
    if (arguments.length == 1)
            return element;
    elements.push(element);
    }
return elements;
}

this is a replacement/enhancement for document.getElementById() and
findObj()

alert($$('Edit1').value);//just get one object

IMO this is very cool in that it can also get an array of objects!!
(includes obj we all ready had found also and real objects like
LabeledEdit)


var elements = $$('Edit2','Edit4','Edit6',obj1,obj2,'Edit5','Edit3');
for (var i=0;i < elements.length; i++) elements[i].value='';
//we just blew through a bunch of edits and cleared them.

The second one, toggle, is for html/css objects and just shows and hides
them. Got a better name suggestion?

function toggle(obj)
{
var el = $$(obj);
if ( el.style.display != 'none' )
        {
        el.style.display = 'none';
        }
 else
        {
        el.style.display = '';
        }
}


Thanks
Gary

Re: [vcl4php-developers] Wiki in Italian

[Jose L. <qa...@gm...>]

Hello
On Tue, Nov 4, 2008 at 3:11 PM, Daniele Teti <d....@bi...> wrote:
> Yesterday night I'm started to translate wiki documentation from english
> to new italian section.
>
> (Thanks José)
>
> Italian Message
> "Ogni aiuto da parte di programmatori italiani sarà ben accetto"
By the way, the italian wiki is here:

http://www.qadram.com/vcl4php/docwiki/it

Regards
-- 
Se aprende más de una derrota que de una victoria, pero la clave está
en no acostumbrarse a perder (Un buen año)

¿Sabes que? Me da igual que sea fabuloso, sólo espero que tenga
suerte. (Match Point)

[vcl4php-developers] Wiki in Italian

[Daniele T. <d....@bi...>]

Yesterday night I'm started to translate wiki documentation from english 
to new italian section.

(Thanks José)

Italian Message
"Ogni aiuto da parte di programmatori italiani sarà ben accetto"


-- 
Daniele Teti
R&D Director & Educational
bitTime Software/CodeGear

[vcl4php-developers] [TEST]

[Daniele T. <d....@bi...>]

Sorry

-- 
Daniele Teti
R&D Director & Educational
bitTime Software/CodeGear

[vcl4php-developers] extctrls.inc.php - Image component

[A. <An...@an...>]

This component's dumpcontents() function messes up the component when the Image's URL is specified by a Datasource field rather than entered into the _imagesource property.

Lines: 

385 to 392:

if (($this->ControlState & csDesigning) != csDesigning)
{
    if ($this->hasValidDataField())
    {
        $this->_imagesource = $this->readDataFieldValue();
        // no hidden field to dump since it's a read-only control
     }
}

need to be moved above line 265

// first let's get the image size
if ($this->_imagesource != "")
{
   if (is_file($this->getImageSourcePath()))
   ...

otherwise all the nice code that makes sure the image looks right gets ignored and the image gets stretched to fit the component's dimensions.

I noticed this when using Image with DBRepeater to make a thumbnail page and most of the thumbnails looked horrid...

Andy

Re: [vcl4php-developers] checkbox fix

[qadram s. <su...@qa...>]

Jonathan Benedicto escribió:
> Hello All,
>  
> I've made some changes to the CustomCheckBox class, that makes its UI 
> more consistent to the Windows checkbox control.
>  
> When changing alignment on the old checkbox, it merely altered the 
> alignment of the text that is located to the right of the checkbox 
> control, but did not alter the position of the checkbox as the Windows 
> checkbox does.
>  
> This change fixes that behaviour, so that aligning the checkbox 
> correctly positions the text/checkbox.
Applied, thanks!!!

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

[vcl4php-developers] Zend include_path suggestion

[Charles S. <ch...@la...>]

Hi Everyone.  May I suggest an addition to the Zend library that would
include the path to the framework so that it doesn't need to be specifically
set in php.ini?

 

File to modify: vcl/Zend/zcommon.inc.php

 

I suggest inserting the following immediately below the copyright comment at
the head of the file:

 

QUOTE

// Add the Zend framework library path to the current include_path

$pathvar = 'vcl/Zend/framework/library';

set_include_path(get_include_path() . PATH_SEPARATOR . $pathvar);

UNQUOTE

I hope this helps.

 

Charles

[vcl4php-developers] database helpers

[Jonathan B. <co...@jo...>]

I've been thinking that we should add some helper functions to the Database class, to make certain kinds of queries easier.

For example, a QueryVar function, that returns the first value in the first column in the result set.

function QueryVar($query,$params=array())
{
    $this->open();
    return $this->_connection->GetOne($query,$params);
}

Jon

Re: [vcl4php-developers] array property access

[Jonathan B. <co...@jo...>]

> And this kind of properties behave well in the IDE with the Object
> Inspector and Form Designer? If so, the change will be really useful.

On further investigation, the change won't be that simple. :-(

1. getclassinfo.php tries to get the types for each property, so returning 
an ArrayObject (which is a true object in PHP), causes getclassinfo to 
process it as an object property. This is not what we want, so we'd have to 
return the actual array in design state. (Problem is - csDesigning isn't set 
by getclassinfo, we'd have to fix this)

2. The VCL streaming operations also get the types for each property, so 
we'd have to return the actual array in the streaming phase. One problem 
here - there is no ControlState for serialization, we'd have to add it.

So, the getter would probably become:

function getProperty()
{
    return ( $this->ControlState != 0 ) ? $this->_Property : new 
ArrayObject( $this->_Property );
}

Jon 

Re: [vcl4php-developers] array property access

[qadram s. <su...@qa...>]

Jonathan Benedicto escribió:
> Hi All,
>  
> This mailing list's been quite quiet :-) Well, I have something to 
> propose which will hopefully make it more active again :-)
>  
> Regarding array access in the VCL. As we all know, accessing array 
> properties via __get returns a temporary array, so one can't do:
>  
> $a->Property[0] = '123';
>  
> This is a significant problem, and makes the property access 
> non-intuitive, because to get the expected result, one has to:
>  
> $temp = $a->Property;
> $temp[0] = '123';
> $a->Property = $temp;
>  
> However, there is another solution, which, in my opinion the VCL should 
> use, as it would allow users to simply do:
>  
> $a->Property[0] = '123';
>  
> and get the expected result.
>  
> This solution doesn't require much code change, all one has to do is 
> replace the getter function, eg:
>  
> function getProperty()
> {
>         return $this->_Property;
> }
>  
> with:
>  
> function getProperty()
> {
>     return new ArrayObject( $this->_Property );
> }
>  
> So, what are your comments, suggestions etc. on this approach? 
> (Personally, if no-one can point out any flaws with it, my components 
> will be switching over to this)
And this kind of properties behave well in the IDE with the Object 
Inspector and Form Designer? If so, the change will be really useful.

Regards
-- 
José León
qadram software
C/Juan Ramón Jiménez, 15 Entlo. 2
03203 Elche ALICANTE (SPAIN)
T: +34 965 45 48 48
F: +34 965 45 48 48
M: +34 618 28 13 69
http://www.qadram.com

[vcl4php-developers] array property access

[Jonathan B. <co...@jo...>]

Hi All,

This mailing list's been quite quiet :-) Well, I have something to propose which will hopefully make it more active again :-)

Regarding array access in the VCL. As we all know, accessing array properties via __get returns a temporary array, so one can't do:

$a->Property[0] = '123';

This is a significant problem, and makes the property access non-intuitive, because to get the expected result, one has to:

$temp = $a->Property;
$temp[0] = '123';
$a->Property = $temp;

However, there is another solution, which, in my opinion the VCL should use, as it would allow users to simply do:

$a->Property[0] = '123';

and get the expected result.

This solution doesn't require much code change, all one has to do is replace the getter function, eg:

function getProperty()
{
        return $this->_Property;
}

with:

function getProperty()
{
    return new ArrayObject( $this->_Property );
}

So, what are your comments, suggestions etc. on this approach? (Personally, if no-one can point out any flaws with it, my components will be switching over to this)

Jon