Hi, I have done some tests with the graph component. SVG output is coolI 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
> Hi, > > I have done some tests with the graph component. SVG output > is cool
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(Continue reading)
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)
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)
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)
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)
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)
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)
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)
RSS Feed1 | |
|---|---|
1 | |
7 | |
3 | |
5 | |
6 | |
7 | |
50 | |
15 | |
17 | |
23 | |
9 | |
22 | |
34 | |
17 | |
16 | |
19 | |
35 | |
40 | |
87 | |
77 | |
67 | |
30 | |
35 | |
18 | |
45 | |
8 | |
28 | |
104 | |
123 | |
43 | |
51 | |
58 | |
63 | |
123 | |
48 | |
97 | |
29 | |
45 | |
130 | |
199 | |
143 | |
186 | |
114 | |
39 | |
74 | |
130 | |
59 | |
68 | |
58 | |
83 | |
207 | |
109 | |
77 | |
266 | |
77 | |
46 | |
106 | |
66 | |
220 | |
134 | |
227 | |
87 | |
249 |
