Kristian Hole | 2 Sep 06:33 2006
Picon

Graph component

Hi,

I have done some tests with the graph component. SVG output is cool :-)

I want to render the graph dynamically every time, so i want to output
it with a PHP file.

I would like to do:

$graph = $chart->render( 500, 200 );
header("Content-type: image/svg+xml");
echo $graph;

It does not seem possible to me that i can render it to anything but a
file, am i right?

Are there any plans for adding this kind of support?

Cheers
Kristian

Jared Williams | 2 Sep 12:54 2006

RE: Graph component

> Hi,
> 
> I have done some tests with the graph component. SVG output 
> is cool :-)
> 
> 
> I want to render the graph dynamically every time, so i want to output
> it with a PHP file.
> 
> 
> I would like to do:
> 
> $graph = $chart->render( 500, 200 );
> header("Content-type: image/svg+xml");
> echo $graph;
> 
> It does not seem possible to me that i can render it to anything but a
> file, am i right?
> 
> Are there any plans for adding this kind of support?

Try using php://output as the filename. Should send it direct with any luck. 

Jared 

Kristian Hole | 2 Sep 17:20 2006
Picon

Re: Graph component

but of course! that works...

thanks Jared.

/K

On 9/2/06, Jared Williams <jared.williams1@...> wrote:
> > Hi,
> >
> > I have done some tests with the graph component. SVG output
> > is cool :-)
> >
> >
> > I want to render the graph dynamically every time, so i want to output
> > it with a PHP file.
> >
> >
> > I would like to do:
> >
> > $graph = $chart->render( 500, 200 );
> > header("Content-type: image/svg+xml");
> > echo $graph;
> >
> > It does not seem possible to me that i can render it to anything but a
> > file, am i right?
> >
> > Are there any plans for adding this kind of support?
>
> Try using php://output as the filename. Should send it direct with any luck.
>
(Continue reading)

Derick Rethans | 4 Sep 14:36 2006
X-Face
Picon

Re: Database testing

On Tue, 1 Aug 2006, Derick Rethans wrote:

> On Wed, 19 Jul 2006, Sergey Alexeev wrote:
> 
> > On ???, 2006-07-19 at 10:02 +0200, Derick Rethans wrote:
> > > On Tue, 4 Jul 2006, Sergey Alexeev wrote:
> > > 
> > > > I could propose to override ezcQuery->prepare() in ezcQuerySelect and
> > > > insert such check in ezcQuerySelect->prepare() method.
> > > > 
> > > > We could check what RDBMS used and look if FROM clause contains
> > > > something. And here we can fix SQL if it necessary before creating
> > > > PDOstatement.
> > > > 
> > > > Any thoughts/suggestions?
> > > 
> > > How expensive would such a check be? IE, is checking for this just an 
> > > "if" or is more needed?
> > 
> > Seems it's not expensive.
> > 
> > It cost calling overrided method
> > and one "if" in it
> > 
> > public function prepare(){
> >    if ( $this->fromString === null || $this->fromString == "" )
> >    {
> >        $this->fromString = $this->getDummyTableName();
> >    }
> >    return parent::prepare();
(Continue reading)

Sergey Alyeksyeyev | 4 Sep 16:04 2006
Picon

Re: Database testing

Hello,

> On Tue, 1 Aug 2006, Derick Rethans wrote:
> 
> > On Wed, 19 Jul 2006, Sergey Alexeev wrote:
> > 
> > > On ???, 2006-07-19 at 10:02 +0200, Derick Rethans wrote:
> > > > On Tue, 4 Jul 2006, Sergey Alexeev wrote:
> > > > 
> > > > > I could propose to override ezcQuery->prepare() in ezcQuerySelect and
> > > > > insert such check in ezcQuerySelect->prepare() method.
> > > > > 
> > > > > We could check what RDBMS used and look if FROM clause contains
> > > > > something. And here we can fix SQL if it necessary before creating
> > > > > PDOstatement.
> > > > > 
> > > > > Any thoughts/suggestions?
> > > > 
> > > > How expensive would such a check be? IE, is checking for this just an 
> > > > "if" or is more needed?
> > > 
> > > Seems it's not expensive.
> > > 
> > > It cost calling overrided method
> > > and one "if" in it
> > > 
> > > public function prepare(){
> > >    if ( $this->fromString === null || $this->fromString == "" )
> > >    {
> > >        $this->fromString = $this->getDummyTableName();
(Continue reading)

Frederik Holljen | 7 Sep 09:56 2006
X-Face
Picon

Re: PersistentObject relation handling design document

Hi Toby,

I through it yesterday evening and I can say it looks really cool! I'll read 
it again today and then come with some more feedback.

Good (and thorough) work!
Frederik

On Wednesday 06 September 2006 17:07, Tobias Schlitt wrote:
> Hi all!
>
> Since relation handling is now an offical agenda point for version 1.2
> of PersistentObject, I created a first design draft for this feature.
> You can find it in SVN [1] as RST or on my website [2] as rendered HTML.
> Please review the document and comment on it!
>
> Thanks!
> Toby
>
> [1]
> http://svn.ez.no/filedetails.php?repname=ezcomponents&path=%2Ftrunk%2FPersi
>stentObject%2Fdesign%2Fdesign-1.2.txt [2]
> http://schlitt.info/ez/persistentobject_1.2.html
> --
> Mit freundlichen Gruessen / Med vennlig hilsen / Best regards
> Tobias Schlitt (GPG Key: 0xC462BC14)
>
> System developer for the eZ components project
>
> ts@... | eZ systems | ez.no
(Continue reading)

Frederik Holljen | 8 Sep 07:54 2006
X-Face
Picon

Re: PersistentObject relation handling design document

Good morning,

> I through it yesterday evening and I can say it looks really cool! I'll
> read it again today and then come with some more feedback.

Basically your design is more or less exactly what I had in mind when the 
basics of Persistent Object where implemented. Because of the lack of code 
manipulation features in PHP there are only two real methods 
1) adding functionality on the persistent object classes
or
2) adding functionality on the session

Out of these two I think your approach is the cleanest one although it is a 
bit more cumbersome to use. As you say we can add a base class that people 
can inherit from in order for the end result to look more like hibernate. It 
might be cool, but if you use both approaches in an application you actually 
need to know what type of PO you are using. Basically you get inconsistent 
usage of POs. I'll have to think a bit about it, but for now I'm against it. 
(feel free to argument against me.. I might change my mind...)

I have one question about the pre loading of objects. If you preload an object 
and someone fetches it. What are you going to serve the next person who 
requests that same object? Since we don't have any automatic dirty checking 
you can not know if that object has been changed or not. An alternative is to 
give him/er access to the very same object. In the case on on demand loading 
are you going to store the loaded objects as well so you can return them if 
it is requested again?

When it comes to dirty checking I agree with you that is to heavy to implement 
it in PHP. What we can do however is to add some dirty functionality to the 
(Continue reading)

Frederik Holljen | 8 Sep 08:47 2006
X-Face
Picon

Re: PersistentObject relation handling design document

Hi,

> > I have one question about the pre loading of objects. If you preload an
> > object and someone fetches it. What are you going to serve the next
> > person who requests that same object? Since we don't have any automatic
> > dirty checking you can not know if that object has been changed or not.
> > An alternative is to give him/er access to the very same object. In the
> > case on on demand loading are you going to store the loaded objects as
> > well so you can return them if it is requested again?
>
> I think we should not leave the problem of 2 people requesting the same
> object to PersistentObject, but to the application and offer a method to
> lock objects (on basis of the underlying database). I don't see, what
> this has to do with the problem of dirty-checking, though, could you
> elaborate a bit more, here?
These two are related because if session knows which objects are dirty you can 
use this information to inform the user when he is requesting or making 
changes to a second copy of the same object.

>
> > When it comes to dirty checking I agree with you that is to heavy to
> > implement it in PHP. What we can do however is to add some dirty
> > functionality to the session:
> > public function setDirty( mixed $persistentObjects );
> > public function updateDirty()
> >
> > This is of course nowhere near automatic but it allows you to register
> > dirty objects while updating them and then have the session commit the
> > changes automatically. The information can perhaps also be used for other
> > things.
(Continue reading)

Frederik Holljen | 8 Sep 10:12 2006
X-Face
Picon

Re: PersistentObject relation handling design document

Ho ho, =)

> >>> I have one question about the pre loading of objects. If you preload an
> >>> object and someone fetches it. What are you going to serve the next
> >>> person who requests that same object? Since we don't have any automatic
> >>> dirty checking you can not know if that object has been changed or not.
> >>> An alternative is to give him/er access to the very same object. In the
> >>> case on on demand loading are you going to store the loaded objects as
> >>> well so you can return them if it is requested again?
> >>
> >> I think we should not leave the problem of 2 people requesting the same
> >> object to PersistentObject, but to the application and offer a method to
> >> lock objects (on basis of the underlying database). I don't see, what
> >> this has to do with the problem of dirty-checking, though, could you
> >> elaborate a bit more, here?
> >
> > These two are related because if session knows which objects are dirty
> > you can use this information to inform the user when he is requesting or
> > making changes to a second copy of the same object.
>
> Maybe we should speak in terms of requests here, not users. ;) That
> makes the situation a bit more clear.
Or within the same php process to be exact.

> So, if during 1 request a 
> persistent object is fetched again, I think the session should actually
> return the already fetched instance. Refetching the object from the
> database is inaccurate, because it destroys already made changes. I
> think we do not need to inform the user that he fetches an object he
> already has. This allows us to use the persistent session as a kind of
(Continue reading)

Frederik Holljen | 8 Sep 11:23 2006
X-Face
Picon

Re: PersistentObject relation handling design document

On Friday 08 September 2006 12:26, Tobias Schlitt wrote:
> On 09/08/2006 10:12 AM Frederik Holljen wrote:
> > Ho ho, =)
>
> Ho ho ho... (oh, now it looks like Xmas...)
>
> >>>>> I have one question about the pre loading of objects. If you preload
> >>>>> an object and someone fetches it. What are you going to serve the
> >>>>> next person who requests that same object? Since we don't have any
> >>>>> automatic dirty checking you can not know if that object has been
> >>>>> changed or not. An alternative is to give him/er access to the very
> >>>>> same object. In the case on on demand loading are you going to store
> >>>>> the loaded objects as well so you can return them if it is requested
> >>>>> again?
> >>>>
> >>>> I think we should not leave the problem of 2 people requesting the
> >>>> same object to PersistentObject, but to the application and offer a
> >>>> method to lock objects (on basis of the underlying database). I don't
> >>>> see, what this has to do with the problem of dirty-checking, though,
> >>>> could you elaborate a bit more, here?
> >>>
> >>> These two are related because if session knows which objects are dirty
> >>> you can use this information to inform the user when he is requesting
> >>> or making changes to a second copy of the same object.
> >>
> >> Maybe we should speak in terms of requests here, not users. ;) That
> >> makes the situation a bit more clear.
> >
> > Or within the same php process to be exact.
>
(Continue reading)


Gmane