[Components] PHP pdiff implementation
Hi, I implemented the pdiff [1] algorithm in PHP, just converted the cpp code to PHP, and it is far to slow, to even think of possible optimizations (and I don't see any real optimizations). It takes about 1m and 30s to compare a single small image on my machine. This would be a major slow down of our test cases, as I currently compare about 75 bitmaps in my tests (would result in a 2h run, without code coverage ;). So what are the options? 1) pdiff now compiles without patching and can compare PNGs with one patch [2] in no time. Is it an option to wait for the patch beeing included and make it an requirement for testing the bitmap stuff? 2) We could convert the cpp code to c and make a pecl extension out of it. This would be far easier to install, on not a really big issue. 3) Evaluate other algorithms / alternatives. The pdiff algorithm works really well (and it is beautiful, look at the code :), and I personally ran out of options. 4) Stay with imagemagick compare, and increase the expected maximum noise distance, but I think we are already beyond any proper testing with the current maximum noise distances. [1] http://sourceforge.net/projects/pdiff [2] http://sourceforge.net/tracker/index.php?func=detail&aid=1748226&group_id=166838&atid=840552 I attached my (not completely working) PHP implementation, if you want to test it yourself, or take a more detailed look at the code. It still has some bug, but fixing this wouldn't solve the performance problem. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no pdiff.php Description: application/php signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: XHtml XSS
On Thu, 2007-07-05 at 10:36 +0200, Derick Rethans wrote: [..] > I think both of those have a merit - I actually think your second idea > is even more elegant as you won't have to deal with all the different > escaping methods yourself. Could you file a task for the first thing, > and an enhancement for the second? Done :) -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 5690 - /trunk/Graph/design/interactive_data_points.txt
Author: kn Date: Thu Jul 5 10:30:03 2007 New Revision: 5690 Log: - Added interactive datapoint requirements document Added: trunk/Graph/design/interactive_data_points.txt (with props) Added: trunk/Graph/design/interactive_data_points.txt == --- trunk/Graph/design/interactive_data_points.txt (added) +++ trunk/Graph/design/interactive_data_points.txt [iso-8859-1] Thu Jul 5 10:30:03 2007 @@ -1,0 +1,77 @@ +eZ component: Graph: Interactive data points, Requirements +~~ + +Introduction + + +Description +--- + +Interactive data points describe a feature in charts, that the viewer of the +chart can interactively get more information about data, when viewing the +chart, or moving his mouse pointer over points of interest in the chart. + +Requirements + + +There are two major sets of features to implement + +Value indication + + +The value indication means, that at the position of the mouse pointer lines +are drawn, depeding on the chart type, to indicate the current data value at +this poistion in the chart. In a line chart this would mean a horizontal and a +vertical line to the axis and some coordinate information at the current +position of the mouse pointer, while in radar chart a line to the center of +the chart and an ellipse, indicating the value on the y axis, needs to be +drawn. + +SVG + No real problem. + +GD / Cairo / IMagick + Not possible without large effort. + +Flash + Evaluation required. Possible with flash, stutus in ext/ming yet unclear. + +Additional data point information +- + +When hovering or clicking on a data point or a legenda ite, a box with +additional information should be displayed. The box should contain text or +user defined content. + +SVG + With only user defined inlined SVGs or Text in a box no big deal. + +GD / Cairo / IMagick + With a tool script generating HTML and javascript to use with the image + map, it should be possible to use HTML and text in boxes. This is similar + to the currently used mechanism to create image maps. + +Flash + Evaluation required. Possible with flash, stutus in ext/ming yet unclear. + +Special consideration += + +It is impossible to implement natively more then simple text in a box for the +additional information in highlighted data points, because this would require +a complete redering model like HTML uses. + +Formats +=== + +The integration of HTML, Flash or SVG documents should be possible, but would +be a non driver generic mechanism. It seems not easily possible to convert +user defined Flash, HTML and SVG to the respective other format. + + +.. + Local Variables: + mode: rst + fill-column: 79 + End: + vim: et syn=rst tw=79 Propchange: trunk/Graph/design/interactive_data_points.txt -- svn:eol-style = native -- svn-components mailing list [EMAIL PROTECTED] http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 5691 - /trunk/Graph/design/multiple_axis.txt
Author: kn Date: Thu Jul 5 10:30:23 2007 New Revision: 5691 Log: - Added multiple axis requirements document Added: trunk/Graph/design/multiple_axis.txt (with props) Added: trunk/Graph/design/multiple_axis.txt == --- trunk/Graph/design/multiple_axis.txt (added) +++ trunk/Graph/design/multiple_axis.txt [iso-8859-1] Thu Jul 5 10:30:23 2007 @@ -1,0 +1,56 @@ +eZ component: Graph: Multiple axis, Requirements + + +Introduction + + +Description +--- + +Multiple axis are used in two different cases. + +- In stock chart, for example, they are used to show a different meaning of + the displayed data, for example the value of a single stock option and the + value sum of the complete company. + +- Another case multiple axis may be used, is displaying relating data in one + chart which has completely different scalings or units, like the used RAM + and the load on a machine. + +A third case multiple axis could be used for, are named separators to +highlight data borders in your chart. In this case the step labels should be +at least optional. + +Requirements + + +To act as additional axis and seperators it is required, that additional axis +can be placed at any position in the chart, especially at the very end and +beginning of the charts data. + +It should be possible to associate a data set with a non default axis, to +calculate the position of its data points based on a diffenrent scaling, then +the default one. + +It should also be possible to add axis not depending on any data set and +define the scaling manually. Those axis can be placed at any position in the +chart, and if no scaling was explicitely given and no data set is associated, +those axis will omit drawing steps or step labeling and just display a single +line with the (optional) axis label. + +Special consideration += + +An API for assigning data sets to axis other then the default one will be +defined in the design document. The calculation of the poistion of a data +point in a chart is completely done in the chart classes, so it will be no +problem to use another axis for this. No changes or additions in the renderers +will be required. + + +.. + Local Variables: + mode: rst + fill-column: 79 + End: + vim: et syn=rst tw=79 Propchange: trunk/Graph/design/multiple_axis.txt -- svn:eol-style = native -- svn-components mailing list [EMAIL PROTECTED] http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] PHP pdiff implementation
On Thu, 2007-07-05 at 13:09 +0200, Jan Borsodi wrote: > On Thursday 05 July 2007 10:19:13 Kore Nordmann wrote: > > Hi, > > > > [...] > > 2) We could convert the cpp code to c and make a pecl extension out of > > it. This would be far easier to install, on not a really big issue. > > Why do you need to convert it to C, I thought it was possible to plug in C++ > code into PHP nowadays? We still need to rewrite / refactor the code to respect thread safety isseus etc., and writing / maintaining C extensions is easier. Converting the simple math code to C is not a big deal either. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Tree requirements (formerly HierarchObject)
On Thu, 2007-07-05 at 15:06 +0200, Derick Rethans wrote: > We also discussed the name, and we think that Tree is more > welcome. With our discussions in mind, I took the liberty of creating a > new requirements document out of the original one by Thomas. You can > read it below. Comments are appreciated: [...] > Design goals > > > It's desirable to have an OO API to handle the nodes like the DOM > extension, e.g. Node->appendChild(). On the other hand it's an advantage > not be obliged to extend an abstract node class when working with the > content of the leaves. Even DOM works quite well, I still don't like it's interfaces. What about implementing RecursiveIterator to access the (sub) trees with a RecursiveIteratorIterator? For adding nodes you still would need those methods, as we see in SimpleXML, solving this with magic properties does not really work well in all cases. Maybe this just belong into the design specs... :) -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] XML text schema for ez publish 4 (draft)
On Thu, 2007-07-05 at 17:53 +0300, Kirill Subbotin wrote: > Tobias Schlitt wrote: > > > Just for curiosity: Why are you using such an EBNF-like format instead > > of a standardized way for describing XML formats, for example > > XML-Schema? We need that later, anyway, so it sounds logical to me to > > use it right from the start. Or am I wrong? > > The reasons were that schemas are harder to read, and too many things were > unclear to > create it. So I've decided to use simplified form to get more responses on > issues. > (but even in this case I'm getting not very much of them) > But now I'm going to create a real scheme, as anyway there is not much > feedback. In this case you may want to consider using the compact syntax from RelaxNG, which es imho really easy to read: http://relaxng.org/compact-tutorial-20030326.html -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] XML text schema for ez publish 4 (draft)
On Thu, 2007-07-05 at 17:11 +0200, Tobias Schlitt wrote: > On 07/05/2007 05:05 PM Kore Nordmann wrote: > > On Thu, 2007-07-05 at 17:53 +0300, Kirill Subbotin wrote: > > >> Tobias Schlitt wrote: > > >>> Just for curiosity: Why are you using such an EBNF-like format instead > >>> of a standardized way for describing XML formats, for example > >>> XML-Schema? We need that later, anyway, so it sounds logical to me to > >>> use it right from the start. Or am I wrong? > >> The reasons were that schemas are harder to read, and too many things were > >> unclear to > >> create it. So I've decided to use simplified form to get more responses on > >> issues. > >> (but even in this case I'm getting not very much of them) > >> But now I'm going to create a real scheme, as anyway there is not much > >> feedback. > > > In this case you may want to consider using the compact syntax from > > RelaxNG, which es imho really easy to read: > > > http://relaxng.org/compact-tutorial-20030326.html > > While this discussion does not really belong to this thread: We should > standardize the way we want to specify XML formats. I still insist on > XML-Schema, since it is a W3C recommendation. The short format of > RelaxNG might be a bit easier to read/write, but it is not an official > standard, or am I wrong? "The RELAX NG specifications have been developed within OASIS by the RELAX NG Technical Committeee. RELAX NG is being developed into an International Standard (ISO/IEC 19757-2) by ISO/IEC JTC1/SC34/WG1; it is currently at the final stage of standardization." But afaik it is not directly related to the w3c in some way, but beeing an OASIS standard and becoming an ISO standard should make it usable for us. I personally like the format for its simplicity, but could also live with XML-Schema. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Schema Validation (Was: Re: XML text schema for ez publish 4 (draft))
On Fri, 2007-07-06 at 15:58 +0200, Derick Rethans wrote: > On Fri, 6 Jul 2007, Derick Rethans wrote: > > > On Thu, 5 Jul 2007, Kore Nordmann wrote: > > > > > "The RELAX NG specifications have been developed within OASIS by the > > > RELAX NG Technical Committeee. RELAX NG is being developed into an > > > International Standard (ISO/IEC 19757-2) by ISO/IEC JTC1/SC34/WG1; it is > > > currently at the final stage of standardization." > > I've done a bit of research, and we can't use the "simple" version here, > as libxml can not use that for validation. The leaves us with either > XML Schema or RelaxNG (normal). I tried trang on our linguist files, and > the results for both schemas can be found as attachments. (Also the > corresponding .rnc). > > XML Schema is quite harder to read, even more if things get more > complex. I would therefore suggest to use RelaxNG as our schema > definition language. > > Let's vote on this: +1 for RelaxNG. +1 for RelaxNG (Surprise! Surprise!) And +1 for RelaxNG-c for discussions. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 5713 - in /trunk/Graph/design/enhancements: ./ interactive_data_points.txt
Author: kn
Date: Tue Jul 10 14:57:55 2007
New Revision: 5713
Log:
- Added first draft of interactive data points design document
Added:
trunk/Graph/design/enhancements/
trunk/Graph/design/enhancements/interactive_data_points.txt (with props)
Added: trunk/Graph/design/enhancements/interactive_data_points.txt
==
--- trunk/Graph/design/enhancements/interactive_data_points.txt (added)
+++ trunk/Graph/design/enhancements/interactive_data_points.txt [iso-8859-1]
Tue Jul 10 14:57:55 2007
@@ -1,0 +1,165 @@
+eZ component: Graph: Interactive data points, Design
+
+
+:Author: $Author:$
+:Revision: $Rev:$
+:Date: $Date:$
+
+Introduction
+
+
+Description
+---
+
+Interactive data points describe a feature in charts, that the viewer of the
+chart can interactively get more information about data, when viewing the
+chart, or moving his mouse pointer over points of interest in the chart.
+
+Requirements
+
+
+There are two major sets of features to implement
+
+Value indication
+
+
+The value indication means, that at the position of the mouse pointer lines
+are drawn, depeding on the chart type, to indicate the current data value at
+this poistion in the chart. In a line chart this would mean a horizontal and a
+vertical line to the axis and some coordinate information at the current
+position of the mouse pointer, while in radar chart a line to the center of
+the chart and an ellipse, indicating the value on the y axis, needs to be
+drawn.
+
+To enable this an option will be added to the driver option classes for the
+drivers, which are capeable of drawing this. The value indication will be off
+by default and can be enabled like this:
+
+::
+
+ $chart->driver->options->valueIndication = true;
+
+This option will be defined in the driver classes for the drivers implementing
+the ezcGraphDriverValueIndication interface. We cannot add those options to
+ezcGraphDriverOptions, because not all drivers will support this new feature,
+and implementing an interface in the driver optoin class makes no sense, as no
+methods, but only properties, will be added.
+
+Driver support
+^^
+
+The driver itself needs to implement a new interface which defines the methods
+required to add the interactive elements to the resulting image. The renderer
+will call those methods on the driver if it implements the interface.
+
+::
+ interface ezcGraphDriverValueIndication
+ {
+ /***
+* Add value indication for a cartesian coordinate system
+*
+* The graph data is rendered in the bounding box, the x values
to
+* indicate start with $xStart up to $xEnd, and the y values
start
+* with $yStart, up to $yEnd.
+*
+* http://en.wikipedia.org/wiki/Cartesian_coordinate
+*
+* @param ezcGraphBoundings $box
+* @param float $xStart
+* @param float $xEnd
+* @param float $yStart
+* @param float $yEnd
+* return void
+*/
+ public function cartesianValueIndication(
+ ezcGraphBoundings $box,
+ $xStart,
+ $xEnd,
+ $yStart,
+ $yEnd
+ );
+
+ /***
+* Add value indication for a polar coordinate system
+*
+* The graph data is rendered in the bounding box, the x values
to
+* indicate start with $xStart up to $xEnd, and the y values
start
+* with $yStart, up to $yEnd. The middle point of the polar
coordinate
+* system is always the center point of the bounding box. The
zero
+* angle may be rotated, depending on the graph rotation.
+*
+* http://en.wikipedia.org/wiki/Polar_coordinate
+*
+* @param ezcGraphBoundings $box
+* @param float $xStart
+* @param float $xEnd
+* @param float $yStart
+* @param float $yEnd
+* return void
+*/
+ public function polarValueIndication(
+ ezcGraphBoundings $box,
+ $xStart,
+ $xEnd,
+ $yStart,
+ $yEnd
+ );
+ }
+
+Additional data point information
+-
+
+When hovering or clicking on a data point or a legenda item, a box with
+additional information should be displayed. The box should contain text or
+user defined content.
+
+The data will be associated with the data point the
[Components] RFC: Design: Interactive data points.
Hi,
After a nearly uncommented requirements document I wrote a first draft
of a design document today. Please comment. :)
There is one general design problem, which you probably should read a
bit more careful then the rest, in the third paragraph in the sub
section "Value indication":
I got an ezc option class, which already extends an existing
option class. (svgDriverOptions extends driverOptions) Now I want to
introduce another set of options there (classical example for multiple
inheritance). What is the cleanest way to do so .. interfaces won't
really help here. Just add the options in all "implementing" classes?
Cause: A new feature which requires new options but can't be
used with all drivers
two options:
1. implement it all the option classes that should support it
2. implement it in the parent class, and exclude them in the
child option classes by making an explicit check for them - and thworing
an exception if it can not be used
I think I prefer 1, but you should ask the list.
In the design doc I go for option 1.
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
eZ component: Graph: Interactive data points, Design
:Author: $Author:$
:Revision: $Rev:$
:Date: $Date:$
Introduction
Description
---
Interactive data points describe a feature in charts, that the viewer of the
chart can interactively get more information about data, when viewing the
chart, or moving his mouse pointer over points of interest in the chart.
Requirements
There are two major sets of features to implement
Value indication
The value indication means, that at the position of the mouse pointer lines
are drawn, depeding on the chart type, to indicate the current data value at
this poistion in the chart. In a line chart this would mean a horizontal and a
vertical line to the axis and some coordinate information at the current
position of the mouse pointer, while in radar chart a line to the center of
the chart and an ellipse, indicating the value on the y axis, needs to be
drawn.
To enable this an option will be added to the driver option classes for the
drivers, which are capeable of drawing this. The value indication will be off
by default and can be enabled like this:
::
$chart->driver->options->valueIndication = true;
This option will be defined in the driver classes for the drivers implementing
the ezcGraphDriverValueIndication interface. We cannot add those options to
ezcGraphDriverOptions, because not all drivers will support this new feature,
and implementing an interface in the driver optoin class makes no sense, as no
methods, but only properties, will be added.
Driver support
^^
The driver itself needs to implement a new interface which defines the methods
required to add the interactive elements to the resulting image. The renderer
will call those methods on the driver if it implements the interface.
::
interface ezcGraphDriverValueIndication
{
/***
* Add value indication for a cartesian coordinate system
*
* The graph data is rendered in the bounding box, the x values
to
* indicate start with $xStart up to $xEnd, and the y values
start
* with $yStart, up to $yEnd.
*
* http://en.wikipedia.org/wiki/Cartesian_coordinate
*
* @param ezcGraphBoundings $box
* @param float $xStart
* @param float $xEnd
* @param float $yStart
* @param float $yEnd
* return void
*/
public function cartesianValueIndication(
ezcGraphBoundings $box,
$xStart,
$xEnd,
$yStart,
$yEnd
);
/***
* Add value indication for a polar coordinate system
*
* The graph data is rendered in the bounding box, the x values
to
* indicate start with $xStart up to $xEnd, and the y values
start
* with $yStart, up to $yEnd. The middle point of the polar
coordinate
* system is always the center point of the bounding box. The
zero
* angle may be rotated, depending on the graph rotation.
*
* http://en.wikipedia.org/wiki/Polar_coordinate
*
* @param ezcGraphBoundings $box
* @param float $xStart
* @param float $xEnd
* @param
Re: [Components] RFC: Design: Interactive data points.
On Tue, 2007-07-10 at 15:15 +0200, Tobias Schlitt wrote: > On 07/10/2007 03:22 PM Kore Nordmann wrote: > > > I got an ezc option class, which already extends an existing > > option class. (svgDriverOptions extends driverOptions) Now I want to > > introduce another set of options there (classical example for multiple > > inheritance). What is the cleanest way to do so .. interfaces won't > > really help here. Just add the options in all "implementing" classes? > > Cause: A new feature which requires new options but can't be > > used with all drivers > > two options: > > 1. implement it all the option classes that should support it > > 2. implement it in the parent class, and exclude them in the > > child option classes by making an explicit check for them - and thworing > > an exception if it can not be used > > I think I prefer 1, but you should ask the list. > > > In the design doc I go for option 1. > > Option 3: Implement it in a new option class and use delegation to this > class for all option classes that should support these. Yes, I like this variant - even we currently would only need to implement in two places, but maybe we get even more interactive output formats (somebody mentions Silverlight?), so it will be even more useful, then. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] My requirement in line-graph with vertical text on X-axis
Hi, On Fri, 2007-07-13 at 10:01 +0530, surej ns wrote: > My project requires ezcompnents Line with GD driver graph. The data on > the x-axis should come vertical currently it is coming as horizontal > text. I plan to plot the values between two weeks. So in one day > there will be more than one entry. so how can I divide each day in > graph ie interval . If u can show me a sample code I would be > thankful. As my requirement is so urgent plz help me out I am not sure if I understand you correctly. I see two points in your question. 1) The interval used on the x axis. You can set the interval used for the steps manually if the automatically guessed value does not fit your requirements. Using a date axis this would look like: $graph->xAxis = new ezcGraphChartElementDateAxis(); $graph->xAxis->majorStep = 12 * 3600; // Half a day. You can find a full date axis example here: http://ez.no/doc/components/view/latest/(file)/introduction_Graph.html#date-time-axis 2) Using rotated texts on an axis You can use diffenrent axis label renderers, one of the is able to draw rotated texts on a axis, even vertical texts. I just noticed, that there is no example for this in the tutorial, I will add an issue for this. Just an example: $chart->xAxis->axisLabelRenderer = new ezcGraphAxisRotatedLabelRenderer(); $chart->xAxis->axisLabelRenderer->angle = 45; You can freely define any angle here. I hoped this helps, please provide more detailed information, otherwise. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Single record display
On Thu, 2007-07-19 at 11:50 +0200, Vít Rozkovec wrote: > Hallo, > how is it possible to achieve a displaying of just a single record in the > graph so it does not look like the right graph on the picture but is shown > as one large bar? > > > The values for this graph is this array (the behaviour is the same for > whatever the key is): > $data = > Array > ( > [19. 07. 2007 05:24] => 3 > ) Yes, it should be possible. Can ypou please open a bug for this on http://issues.ez.no. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Graph axis minValue and maxValue assign
On Thu, 2007-07-19 at 11:56 +0200, Vít Rozkovec wrote:
> Shouldn't it be possible to assign minValue and maxValue of the axis directly?
>
> If so, then this should be added to __set() function in
> Graph/src/axis/numeric.php (not sure about the cast)
>
>case 'minValue':
> if ( !is_numeric( $propertyValue ) )
> {
> throw new ezcBaseValueException( $propertyName,
> $propertyValue, 'float' );
> }
>
> $this->properties['minValue'] = (float) $propertyValue;
> break;
> case 'maxValue':
> if ( !is_numeric( $propertyValue ) )
> {
> throw new ezcBaseValueException( $propertyName,
> $propertyValue, 'float' );
> }
>
> $this->properties['maxValue'] = (float) $propertyValue;
> break;
minValue and maxValue are internal variables used to store the real
minimum and maximum. You can set the display minimum and maximum using
the properties min and max, like:
$chart->yAxis->min = 10;
$chart->yAxis->max = 50;
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] RFC: Design: Interactive data points.
On Sun, 2007-07-22 at 12:25 +0200, Frederik Holljen wrote: > On Tuesday 10 July 2007 15:22, Kore Nordmann wrote: > > Hi, > > > > After a nearly uncommented requirements document I wrote a first draft > > of a design document today. Please comment. :) > > Does this spec allow for custom URL's/javascript methods when making > imagemaps > to be used on webpages? I.e click on the data and get redirected to a page > with more info on that specific data? We already support this. ;) -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PHP pdiff implementation
On Sun, 2007-07-22 at 10:54 +0200, Frederik Holljen wrote: > On Thursday 05 July 2007 13:24, Kore Nordmann wrote: > > On Thu, 2007-07-05 at 13:09 +0200, Jan Borsodi wrote: > > > On Thursday 05 July 2007 10:19:13 Kore Nordmann wrote: > > > > Hi, > > > > > > > > [...] > > > > 2) We could convert the cpp code to c and make a pecl extension out of > > > > it. This would be far easier to install, on not a really big issue. > > > > > > Why do you need to convert it to C, I thought it was possible to plug in > > > C++ code into PHP nowadays? > > > > We still need to rewrite / refactor the code to respect thread safety > > isseus etc., and writing / maintaining C extensions is easier. > > Converting the simple math code to C is not a big deal either. > > Excuse my ignorance, but what is the reason for going through all of this > hassle? What exactly will we use pdiff for? We want to be able to compare image results in unit tests. This simply does not work with the current approach. We get a lot of failures, just because the comparision fails, where the image is perceptually the same. The binary images change with each revision of GD and sometimes it even seems to depend on the platform you use. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Scripts - SUMZERO invoked
On Thu, 2007-07-26 at 18:40 +0200, Frederik Holljen wrote: > Alrighto.. I've update the possibilities with the comments from the > discussion. Time to sumzero. > > Original introduction: > > As discussed we want to include a console script for DatabaseSchema for > > loading and saving schemas from or to disk. The question is; where do we > > put such scripts. We have quite a few options: > > The options > 1. Make one separate scripts component for _all_ scripts >+ all scripts gathered >- this component will have a lot of requirements and may pull in all of > ezc > > > 2. Make a scripts directory in the src dir of a component >+ script together with the component where it belongs >- can add (optional) requirements to the component > > 3. Make a new scripts component for each component named > ezcComponentNameScripts >+ Nice handling of requirements > - Lots of components 1. -1 2. ±0 3. +1 > Fight! > Frederiko -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Email address validation (issue 8436) - SUMZERO
*vote* > 1. Which regexp to use for email validation? > > a. > http://cvs.php.net/viewvc.cgi/pear/HTML_QuickForm/QuickForm/Rule/Email.php?revision=1.4&view=markup > b. http://iamcal.com/publish/articles/php/parsing_email/ > c. http://code.iamcal.com/php/rfc822/full_regexp.txt > d. http://ex-parrot.com/~pdw/Mail-RFC822-Address.html > e. http://www.tienhuis.nl/files/email_verify_source.php > f. This one (please specify): _ > g. Write our own one h) ... no opinion ;) > 2. Do we need to support conversion to Puny code > (http://en.wikipedia.org/wiki/Puny_code)? > > a. NO WAY! > b. No > c. Not now > d. Yes > e. YES WAY! e) ... I think, that email validation without supporting puny code is kind of useless. > 3. If the answer to question 2 was one of c, d or e, then where to put > the unicodeToPunyCode convert function (and the reverse function)? > > a. Mail > b. Url > c. Base > d. UserInput > e. a Tiein (please specify): ___ > f. I can tell you where to put it! a) ... because I still think it should be used by default. > 4. If the answer to question 2 was one of c, d, or e, how should the > unicodeToPunyCode function be triggered? > > a. Automatically everytime > b. Automatically if the email address contains characters outside of ASCII > c. Based on a function parameter, default false > d. Based on a class option, default false > e. Called manually by user > f. It should be hidden, with private and @ignore tags, and with an > obfuscated name, so that nobody will ever know it's there and nobody > will ever call it b) > 5. How many functions which deal with email address validation should we > have? > > a. A function which does everything (regexp, mx, punycode) in one step, > with no possibility of changing the behaviour > b. A function in which the parameters say if the function should do mx > and punycode, which are not done by default > c. A function in which the class options say if the function should do > mx and punycode, which are not done by default > d. 3 functions, one for each step (regexp, mx, punycode). These will be > called independently > e. 4 functions (the 3 functions from d and the function from b) > f. 4 functions (the 3 functions from d and the function from c) > g. 7 functions (regexp, mx, punycode, regexp+mx, regexp+punycode, > mx+punycode, regexp+mx+punycode) h) One function which does regexp + punycode and optionally MX. > All questions are mandatory (except for 3 and 4 which need to be > answered only in case of c, d or e answer for question 2). There should > be a maximum number of 1 (one) answer per question. Your answer should > be in this form (example): I skip the first one, no matter what you say. ;) ... I can not properly evaluate the regular expressions right now to give a definite answer. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Bug #11180 - BC break?
Hi,
I got a fix for issue #11190 [1] ready (patch attached), but I wonder if
we should consider this a BC break.
The issue:
Palettes define the colors used for data sets and single data points in
pie charts.
In pie charts for now the second color has been choosed for the first
pie element - which obviously seems incorrect. The fix is quite easy,
but will change the colors of all yet rendered pie elements in pie
charts. Other chart types are not affected.
Should this be considered as a bug (-1), or a feature (+1)?
[1] http://issues.ez.no/11180
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
Index: Graph/src/interfaces/palette.php
===
--- Graph/src/interfaces/palette.php (revision 5774)
+++ Graph/src/interfaces/palette.php (working copy)
@@ -158,6 +158,17 @@
}
/**
+ * Manually reset the color counter to use the first color again
+ *
+ * @access public
+ */
+public function resetColorCounter()
+{
+$this->colorIndex = -1;
+$this->symbolIndex = -1;
+}
+
+/**
* Returns the requested property
*
* @param string $propertyName Name of property
Index: Graph/src/data_container/single.php
===
--- Graph/src/data_container/single.php (revision 5774)
+++ Graph/src/data_container/single.php (working copy)
@@ -37,6 +37,9 @@
{
parent::addDataSet( $name, $dataSet );
+// Resette palette color counter
+$this->chart->palette->resetColorCounter();
+
// Colorize each data element
foreach ( $this->data[$name] as $label => $value )
{
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Bug #11180 - BC break?
On Thu, 2007-08-02 at 11:52 +0200, Alexandru Stanoi wrote: > Frederik Holljen wrote: > >> I think the voting should be +1/0 not +1/-1, because it would be easier > >> to count, just add how many 1s. It seems confusing (for me anyway) to > >> see -1 which kind of means "substract one from the total number of > >> votes"? Just a thought... > > Huh? You only have one vote afaik. One +1 > > I guess this was what I meant. :) So what I wanted to say is that there > should not be a -1 vote. If you vote +1, 0, -1 you can add up the votes and get a clear result. If the sum is positive it can be considerd a bug. Plus, you may vote 0, if it is neither a "feature" nor a bug from your point of view, but you are ~undecided. As long everybody understands how to vote it does not really matter, imho. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] ezcGraph bounds
Hi, On Fri, 2007-08-03 at 11:42 -0700, Sean Tobin wrote: > I'm trying to render a pie chart without a legend or title, so the pie > itself takes up 100% of the requested area and I'm having some > difficulty. What is happening is that I'm getting the chart, but it is > a fraction of the rendered area. > > See http://24.234.155.62/documents/pie.png for an example of what is > happening. > > I've set: > $graph->legend = false; > $graph->title=false; > $graph->options->label=false; > > and, although they do not show it seems that they are still taking up > space. Does anyone have an idea as to what I can do to increase the > size of the actual pie in relation to the overall image? The space is reserved for labels of the chart. If you want to force to use the complete space you may define it in the renderer; > $renderer->options->pieHorizontalSize = 1; > $renderer->options->pieVerticalSize = 1; This should increase the pie charts size to use the full chart. You may find the complete list of renderer options here: http://ez.no/doc/components/view/latest/(file)/Graph/ezcGraphRendererOptions.html#prop-$pieHorizontalSize -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] maneuvering the components documentation
On Tue, 2007-08-07 at 11:31 +0200, Martin Sommervold wrote: > Hi there, > > I’m new to components and I am having a hard time finding my way > around the documentation. > > Assuming that I do something like this (excerpt from tutorials): > > $graph = new ezcGraphBarChart(); > $graph->options->highlightFont->background = '#EC88'; > > How can I find a list of the elements that are available under > $graph->options ? Say highlightFont for instance? You can find the options described in the API documentation of the component. The correct classes for this are ezcGraphChartOptions [1] and ezcGraphLineChartOptions [2]. The second one describes the options to configure the highlight string. I think I will try to make those option classes more visible in the class documentation - feel free to open an issue for this at http://issues.ez.no/. > More specifically I am trying to center the highlight label above a > the bars in a bar chart, instead of having it to the side of the bar. The highlight labels are currently always centered in the box between the steps. For other (better) positioning algorithms you may open a feature request describing what your intention is here. > Also, how can I space labels away from the axis? As it is now, the > label and measurements get cramped up next to the bars and axes. I assume you are using the SVG driver. For now it is not possible to determine the text width absolutely exact - the tutorial describes it in some more detail [3]. You may use the according options in the SVG driver to change the values for font width guessing [4]. We will probably address this issue by evaluating #10957 [5]. [1] http://ez.no/doc/components/view/latest/(file)/Graph/ezcGraphChartOptions.html [2] http://ez.no/doc/components/view/latest/(file)/Graph/ezcGraphLineChartOptions.html [3] http://ez.no/doc/components/view/latest/(file)/introduction_Graph.html#svg-driver [4] http://ez.no/doc/components/view/latest/(file)/Graph/ezcGraphSvgDriverOptions.html [5] http://issues.ez.no/10957 -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Webdav design document
Hi list, Toby and I finished a first revision of the webdav design document which you may find in SVN [1] and attached to this mail. There are two major points of discussion left for us, which are described at the end of the document. 1) Indication of supported mechanism in backend handlers. 2) Selection of best transport handler for requesting client. If there are no general comments or other suggestions how to solve these two design issues we will start a SUMZERO on this, soon. [1] http://svn.ez.no/svn/ezcomponents/experimental/Webdav/design/design.txt -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no eZ component: Webdav, Design, 1.0 ~ :Author: Kore Nordmann, Tobias Schlitt :Revision: $Rev$ :Date: $Date$ :Status: Draft .. contents:: Scope = The scope of this document is to describe the initial design of a component that provides a WebDAV server, which works with all major other implementations of the WebDAV_ protocol. .. _WebDAV_: http://en.wikipedia.org/wiki/WebDAV It is currently not planned to also offer a WebDAV client component. Design overview === Because of the variaty of buggy and incomplete implementations of WebDAV, this component will provide an abstraction to suite the different needs. Beside that, an abstract interface to the backend will be provided. The main class of this component will provide a fully `RFC 2518`_ compliant implementation of a WebDAV_ server. An instance of this class retrieves an instance of a handler class, which takes care for performing the requested operations on a backend (for example the filesystem). .. _`RFC 2518`: http://tools.ietf.org/html/rfc2518 Additionally, a collection of classes, which inherit the main class will be provided. Each of this classes will provide a compatibility layer on top of the RFC implementation, which works correctly with one or more "buggy" WebDAV clients. A factory pattern implementation will be provided, which takes automatically care of creating the correct server instance for a client. Tiers = The component is basically devided into 3 tiers: The top tier, being represented by the main server class. An instance of this class is responsible to dispatch a received request to a correct transport handler, which is capable of parsing the request. The transport handler level is the second tier. Classes in this tier are responsible to parse an incoming request and extract all relevant information to generate a response for it into a struct object. These struct object is then passed back to the server object. Based on the request struct object, the server checks the capabilities of its third tier, the used backend handler. If the handler object provides all necessary capabilities to generate a response, it is called to do so. If the server class can perform emulation of not available capabilities and rely on different features of the backend. In case there is no way, the backend can handle the request, the server class will indicate that with an error response. The way back flows through the 3 tiers back again: The backend handler generates a response object, which is passed back to the main server object, which makes the active transport handler encode the response and sends it back to the client. Classes === ezcWebdavServer --- The ezcWebdavServer class is the main class of the package. It has to be instantiated to create a server instance and provides a method to get the server up and running. An object of this class takes the main controll over serving the webdav service. Among the configuration of the server instance there must be: A backend handler object, which will be used to serve the received WebDAV requests. A fitting configuration for the backend handler. A collection of transport handlers which can be used to parse incoming requests. General configuration on the bevahiour of the server instance (like locking and stuff). The backend handler object must extend the base class ezcWebdavBackendHandler and must indicate to the main server, which capabilities it provides. The server class can potentially emulate certain capabilities, if the handler does not provide it. An example here is locking, which can be either performed by the handler itself or the main server class. Such emulation functionality could possibly be extracted to a third category of classes, which is only loaded by the main server object on-demand. All configured transport handlers must implement the interface ezcWebdavTransportHandler, which defines the necessary methods. ezcWebdavBackendHandler --- All backend handlers for the Webdav component must extends this abstract base class and implement its abstract methods for very basic WebDAV serving. The operations d
[svn-components] 5832 - /experimental/Webdav/design/design.txt
Author: kn Date: Tue Aug 7 13:21:02 2007 New Revision: 5832 Log: - Clarify, that the server always contains a predefined set of registered transport handlers Modified: experimental/Webdav/design/design.txt Modified: experimental/Webdav/design/design.txt == --- experimental/Webdav/design/design.txt [iso-8859-1] (original) +++ experimental/Webdav/design/design.txt [iso-8859-1] Tue Aug 7 13:21:02 2007 @@ -92,6 +92,13 @@ All configured transport handlers must implement the interface ezcWebdavTransportHandler, which defines the necessary methods. + +The standard webdav server contains a list of transport handlers associated +with regular expressions which should match the client name to be used. As a +fallback the standards compliant transport handler will be used. + +Special implementation added by the user will be add on top of the list, to be +used at highest priority. ezcWebdavBackendHandler --- -- svn-components mailing list [EMAIL PROTECTED] http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] Webdav design document
On Tue, 2007-08-07 at 13:11 +0200, Kore Nordmann wrote: > Hi list, > > Toby and I finished a first revision of the webdav design document which > you may find in SVN [1] and attached to this mail. > > There are two major points of discussion left for us, which are > described at the end of the document. > > 1) Indication of supported mechanism in backend handlers. > > 2) Selection of best transport handler for requesting client. One clarification from revision #5832 of the design document which was not really clear before. "The standard webdav server contains a list of transport handlers associated with regular expressions which should match the client name to be used. As a fallback the standards compliant transport handler will be used. Special implementations added by the user will be add on top of the list, to be used at highest priority." -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Webdav design document
On Tue, 2007-08-07 at 13:42 +0200, Thomas Nunninger wrote: > Hi, > > On Di, 2007-08-07 at 13:11 +0200, Kore Nordmann wrote: > > Hi list, > > > > Toby and I finished a first revision of the webdav design document which > > you may find in SVN [1] and attached to this mail. > > looks nice > > > There are two major points of discussion left for us, which are > > described at the end of the document. > > > > 1) Indication of supported mechanism in backend handlers. > > I like OO - but I guess having a bitmap is the easiest for handling... > > > 2) Selection of best transport handler for requesting client. > > I don't like the idea, that a user needs to define all that regular > expressions because than you'd need to have all clients for testing. It > would be nice if you provide a lightweight class, e.g. > eczWebdavTransportParser, that does the necessary parsing. > > > $server = new ezcWebdavServer(); > > // Server data using file backend with data in "path/" > $server->backend = new ezcWebdavBackendFile( '/path' ); > $server->transportParser = new ezcWebdavTransportParser(); > > // Serve requests > $server->handle(); As clarified in my later mail, you would only need to do this if you want to add your own custom transport mechanism. The default set should normally be enough for every user. > If you want to, you could limit the number of allowed transports e.g. > > $server->transportParser->disableMicrosoft = true; We thought about disabling some transport mechanism, but you could still overwrite them. But I doubt there is need for this at all, because the special handlers should only bypass defects in the clients - which you normally always want. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PHP pdiff implementation
On Mon, 2007-07-23 at 13:22 +0200, Alexandru Stanoi wrote: > Frederik Holljen wrote: > >> pdiff is an algorithm to compare images, in a better way than our test > >> cases do now. > > > > Isn't it a bit overkill to start porting c++ applications etc. just to be > > able > > to do that? I mean, we have to maintain this stuff as well. > > I also think we should not spend too much time on this, and instead use > one of the other options suggested by Kore in the original email > (patched pdiff, pdiff as pecl extension, other programs, imagemagick). "pdiff as pecl extension" is exactly what we are dooing here. > Maybe somebody from the community can provide a better solution? There seems to be nothing in this field - I even no some other persons looking for a proper solution to compare images... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Design: Multiple axis in chart
Hi, From the requirements document discussed earlier I created the design document for the multiple axis feature in ezcGraph. You can find it in SVN [1] and attached to this mail. No big deal in the document - more or less the only thing to chose about are the property names. Everything else seems to be natural deduction from the design of ezcGraph. [1] http://svn.ez.no/svn/ezcomponents/trunk/Graph/design/enhancements/multiple_axis.txt -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no eZ component: Graph: Multiple axis, Design ~~ :Author: $Author: kn $ :Revision: $Revision: 5847 $ :Date: $Date: 2007-08-08 12:26:43 +0200 (Wed, 08 Aug 2007) $ Introduction Description --- Multiple axis are used in three different cases. - In stock chart, for example, they are used to show a different meaning of the displayed data, for example the value of a single stock option and the value sum of the complete company. - Another case multiple axis may be used, is displaying relating data in one chart which has completely different scalings or units, like the used RAM and the load on a machine. - A third case multiple axis could be used for, are named separators to highlight data borders in your chart. In this case the step labels should be at least optional. Requirements From an implementation point of view the feature seperates into two different APIs we need to define. Adding additional axis ^^ When adding additional axis we want to support a finite number of marker axis, at every possible position in the chart. :: $marker = new ezcGraphChartElementLabeledAxis(); $marker->position = ezcGraph::LEFT; $marker->chartPosition = .4; $chart->additionalAxis[] = $marker; The property $position is already used by ezcGraphChartElement to indicate the overall position and accepts bitmasks of LEFT, RIGHT, BOTTOM and TOP. For Axis this indicates the base point of the axis and for additional axis it will define wheather the new axis is an X or Y axis in the cartesian coordinate system of bar and line charts. As the property $position is already used the property $chartPosition indicates the position of the axis in the charts data section. A value of 1 will place the axis at the very end, and a value of 0 at the very beginning of the data. In the example above ezcGraph::LEFT means that the axis is drawn from the left to the right, so it is an additional x axis, and the $chartPosition indicates the position at 40% of the chart data bounding height. Adding data for additional axis ^^^ Data may be added explicitely on one of the additional axis to use different scaling und units for this dataset. The axis values are received from the data sets when rendering the charts, so that we are able to define the usage of an additional axis at any point before rendering. :: $chart->data['foo'] = new ezcGraphArrayDataSet( ... ); $chart->data['foo']->xAxis = $marker; // See last example $chart->data['foo']->yAxis = $chart->yAxis; // Redundant The assignement of additional axis is optional and if none was defined the original common chart axis will be used. You may define custom axis for one or both axis. Special consideration = You may of course define custom scaling, custom axis types and custom axis label rendering algorithms for each of the used axis. If no data set has been assigned to a axis it will not render any labels by using the ezcGraphAxisNoLabelRenderer. Otherwise the assigned data will be used the common way to calculate some default step sizes. .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79 signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Design: Multiple axis in chart
On Wed, 2007-08-08 at 13:26 +0200, Alexandru Stanoi wrote: > Kore Nordmann wrote: > > Hi, > > > > From the requirements document discussed earlier I created the design > > document for the multiple axis feature in ezcGraph. You can find it in > > SVN [1] and attached to this mail. > > > > No big deal in the document - more or less the only thing to chose about > > are the property names. Everything else seems to be natural deduction > > from the design of ezcGraph. > > > > > :: > > > > $marker = new ezcGraphChartElementLabeledAxis(); > > $marker->position = ezcGraph::LEFT; > > $marker->chartPosition = .4; > > > > $chart->additionalAxis[] = $marker; > > > > The property $position is already used by ezcGraphChartElement to indicate > > the > > overall position and accepts bitmasks of LEFT, RIGHT, BOTTOM and TOP. For > > Axis > > this indicates the base point of the axis and for additional axis it will > > define wheather the new axis is an X or Y axis in the cartesian coordinate > > system of bar and line charts. > > > > As the property $position is already used the property $chartPosition > > indicates the position of the axis in the charts data section. A value of 1 > > will place the axis at the very end, and a value of 0 at the very beginning > > of > > the data. > > > > In the example above ezcGraph::LEFT means that the axis is drawn from the > > left > > to the right, so it is an additional x axis, and the $chartPosition > > indicates > > the position at 40% of the chart data bounding height. > > Does it sound better to say HORIZONTAL to specify the X axis, instead of > LEFT? > > It's a little confusing in my opinion to say LEFT and to mean "left to > right". You may want to specify the direction of the axis (from right to left). And this is already done this way since the very first revision. As HORIZONTAL is already used somewhere else we can't make it an alias, but if you like another name for it I could create an constant alias for it. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Webdav design document
On Wed, 2007-08-08 at 14:00 +0200, Derick Rethans wrote: > On Tue, 7 Aug 2007, Kore Nordmann wrote: > > 2) Selection of best transport handler for requesting client. > > In your example code I see that the user has to register the transports > - just like with the Document design I don't think users should > generally be bothered with this. So for the default supported clients we > should pre-register them. As for the canParse() bit - I think that would > be better then just a regular expression. The Feed (hehe) component does > do something similar. As clarified in my follow up mail, a standard set of transport handlers is always registerd by default - you would just need to do this for custom handlers. I see a bit of a difference compared with feed, because I don't think you ever need more then the client name to decide which handler to use - and this spares us the loading of several classes on each request. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] File class/component
On Mon, 2007-08-13 at 09:46 +0200, Derick Rethans wrote: > I feel option 3 to be the cleanest, any opinions? If not I'd like to > implement this ASAP - either today or tomorrow. +1 @ 3 -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 5883 - /trunk/Graph/tests/driver_svg_test.php
Author: kn
Date: Mon Aug 13 10:56:46 2007
New Revision: 5883
Log:
- Try more locale names to switch locale to de_DE
# With http://www.phpunit.de/ticket/183 we can mark this test skipped, if it
# still does not work
Modified:
trunk/Graph/tests/driver_svg_test.php
Modified: trunk/Graph/tests/driver_svg_test.php
==
--- trunk/Graph/tests/driver_svg_test.php [iso-8859-1] (original)
+++ trunk/Graph/tests/driver_svg_test.php [iso-8859-1] Mon Aug 13 10:56:46 2007
@@ -1827,7 +1827,7 @@
public function testSvgWithDifferentLocales()
{
-$this->setLocale( LC_NUMERIC, 'de_DE' );
+$this->setLocale( LC_NUMERIC, 'de_DE', 'de_DE.UTF-8', 'de_DE.UTF8',
'deu_deu', 'de', 'ge', 'deutsch', '[EMAIL PROTECTED]' );
$filename = $this->tempDir . __FUNCTION__ . '.svg';
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] help with using the Graph component
On Sat, 2007-08-18 at 21:50 -0400, Rick Harding wrote: > I've gotten the graphing working and I definitely like how it's going. > There are a few tweaks I'd like to do to get things just working a > little better. > > 1) I'd like to not display a bar graph with highlighting when the > value is 0. The highlight runs into the x-axis lables. We can fix this for 0 values - please report a bug for this in our issue tracker [1]. This won't help for very small negative values (-.0001), though - because the label will be placed below the bar for negative values, which will fit better in most cases. You may define a background and border for the highlicht values, which would always make them readable: http://ez.no/doc/components/view/latest/(file)/Graph/ezcGraphLineChartOptions.html > 2) I can't seem to customize the y-axis to display more gradients so > that it's easier to tell where the graph is. I've tried playing with > the major/minor steps, but I don't think I'm really getting what these > steps are. Steps, or Ticks, mean the interval those small lines are placed on the axis, and where the grid will be placed. In you example you probably want to do something like: $graph->yAxis->mayorStep = 2.5; $graph->yAxis->minorStep = .5; > 3) Is there some manor to adjust the left margin? It's a bit large as > is when you're not using a key there. For now you can only define the same margin for the left and the right side, OR for bottom and top. This will reduce left and right margin: $graph->yAxis->axisSpace = .05; [1] http://issues.ez.no -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 5956 - /experimental/Webdav/design/design.txt
Author: kn Date: Tue Aug 28 10:38:15 2007 New Revision: 5956 Log: - Resolved open issues from discussion Modified: experimental/Webdav/design/design.txt Modified: experimental/Webdav/design/design.txt == --- experimental/Webdav/design/design.txt [iso-8859-1] (original) +++ experimental/Webdav/design/design.txt [iso-8859-1] Tue Aug 28 10:38:15 2007 @@ -113,9 +113,12 @@ - propFetch() All other WebDAV operations are optional to be implemented by a backend handler -and are defined by the handler itself. It is an open issue, if the handlers -should implement different interfaces, to indicate different capabilities or if -a bitmask is more efficient here. +and are defined by the handler itself. The additional basic capabilities of +backend handlers are indicated by implementing interfaces for the support +additional request methods, like put, change, etc. + +Additional features, like encryption support will be indicated by returning a +bitmask of supported features by the backend handler. The logical groups of capabilities are: @@ -173,8 +176,10 @@ request was handled correctly, or a corresponding ezcWebdavErrorResponse object, if the request failed. -An open issue is, how the server instance can figure out best, which transport -to use - see below for this. +The main server instance will know about available clients and will have a +regular expression for each of them, to identify the clients it communicates +to by matching the regualr expression against the client name provided in the +HTTP headers. Example code @@ -191,7 +196,10 @@ // Server data using file backend with data in "path/" $server->backend = new ezcWebdavBackendFile( '/path' ); -// Register transport handlers +// Optionally register aditional transport handlers + // + // This step is only required, when a user wants to provide own + // implementations for special clients. $server->registerTransportHandler( // Regular expression to match client name '(Microsoft.*Webdav\s+XP)i', @@ -208,80 +216,6 @@ // Serve requests $server->handle(); -Open issues -=== - -There are several open issues which need to be discussed before starting to -implement this design: - -Capabilities - - -Backend handlers can offer several different capabilities as noted in the -specific section. It is not set, if the indication of supported capabilities -should be done by implementing interfaces or going another way. - -Implementing interfaces would be a nice, OO-style solution, but can possibly -end up in a huge lot of interfaces and possibly with interfaces that don't -indicate any methods. For example, every handler needs to support GET and can -optioanlly support partial GET. There are several ways, how a handler can -indicate that he supports this: - -The implementation of an interface is the most plausible one: :: - - - -Going this way, we end up with 1 method for every special case for a -handler, which will result in messy code in the main server class, which needs -to check for several methods and interfaces, which could satisfy a request and -then choose the right method of the right interface to perform the work. -Combination of partial *and* - for exampel - encoded request support would -require to define a custom interface here which would end up in 2^$features -interfaces and methods. - -The second option is, to let the handler implement empty interfaces and just -let those be used for declarative purposes. That way, the above shown example -would implement :: - - - -The server class could then use the interface to determine the capability of -partial GET and utilize the usual get() method to initialize the operation and -possibly add a parameter for partiality to the request struct. - -The third alternative is to not use interfaces but a bitmask for handlers to -indicate their capabilities. This will possibly the fastest way, because one -can define fine graned stages of capability support and can easily check on -different capabilities. - -Suitable transport --- - -Another open issue is the mechanism to identify a suitable transport handler -for a certain request. Currently, the main server instance will know about -available clients and will have a regular expression for each of them, to -identify the clients it communicates to. The regex must be defined by the user, -when registering the handler. - -It is not clear, if 1 regex into 1 header field is enough to identify the -handler correctly every time. Therefore, it must be discussed, if handlers -shouldn't better have a static method like canParse() to perform the parsing -checks on their own. That way, the mechanism to identify the correct handler is -much more flexible, but all classes need to be loaded on every request. - .. Local Variables:
Re: [Components] Template: includes and use variables
On Wed, 2007-08-29 at 12:05 +0200, Raymond Bosman wrote:
> Hi all,
>
> This mail describes a problem we currently have with ezcTemplate and it
> provides some solutions. Feedback is highly appreciated.
>
>
> Problem
> ---
> In a system with lots of nested templates or template overrides the amount of
> variables that need to be forwarded to each template may grow out of
> proportion.
Didn't we "invent" this mechanism exactly to make the available
variables more user visible? And wouldn't all the solutions bypass this
explicit declarations, no matter which of the options you choose?
I personally don't really like to change this.
This reminds me of some email I sent earlier about the send_array
construct to pass larger amounts of variales where we concluded that
this would make available variables less visible, so we should propose
another mechanism. The "solution" back then was, to include the sub
template from your application and return the result to the main
template which may echo it anywhere using {raw}.
I see the problem with big applications where a lot of data is required
to pass, but imho there are also some solutions beside passing the
complete local scope at all:
1) Use Structs / Objects
You may combine lots of information in some structs or objects
representing logical objects in your application, and pass nothing more
but them, like a $request-Struct containing all request information.
You are probably already dooing this, but the logical seperations still
result in too many variables?
2) Use custom template functions
For most data an application needs to populate to its templates we
probably could just use custom template functions, which give access to
certain scopes of data.
I don't know how easy it is for now to embed this somehow statically, so
that it is cached in an optimal way - you know more about this ;).
Requiring static cache blocks everywhere won't be nice, so maybe it
could be possible to define that a function returns "static" data in the
template function definition and then include this data statically in
the template?
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: includes and use variables
On Wed, 2007-08-29 at 13:50 +0200, Raymond Bosman wrote:
> > 1) Use Structs / Objects
> >
> > You may combine lots of information in some structs or objects
> > representing logical objects in your application, and pass nothing more
> > but them, like a $request-Struct containing all request information.
> >
> > You are probably already dooing this, but the logical seperations still
> > result in too many variables?
>
> Something like?:
>
> {use $send}
> {$send->a}
> {$send->b}
>
> And $send is a default object send to each Template?
Hmm, nice idea. :)
I just thought about sending it using the usual (implemented) mechanism:
{include 'sub_template.ezt' send $sendObject}
But defining a default set of variables which will be sent to each
template, no matter where it will be included is also something that
could work.
>
> > 2) Use custom template functions
> >
> > For most data an application needs to populate to its templates we
> > probably could just use custom template functions, which give access to
> > certain scopes of data.
>
> Something like?:
>
> {var $send = sendVariables()}
> {$send->a}
> {$send->b}
Yes, exactly. Or just:
{var $foo = ezpGetImportantStuff( 'foo' )}
I am dooing this for example for globally defined metadata directly
mapping to a ezcConfiguration::getSetting() in one of my projects. (Of
course with some caching in place)
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: includes and use variables
On Wed, 2007-08-29 at 16:05 +0200, Frederik Holljen wrote:
> On Wednesday 29 August 2007, Kore Nordmann wrote:
> > On Wed, 2007-08-29 at 13:50 +0200, Raymond Bosman wrote:
> > > > 1) Use Structs / Objects
> > > >
> > > > You may combine lots of information in some structs or objects
> > > > representing logical objects in your application, and pass nothing more
> > > > but them, like a $request-Struct containing all request information.
> > > >
> > > > You are probably already dooing this, but the logical seperations still
> > > > result in too many variables?
> > >
> > > Something like?:
> > >
> > > {use $send}
> > > {$send->a}
> > > {$send->b}
> > >
> > > And $send is a default object send to each Template?
> >
> > Hmm, nice idea. :)
> It's basically a global variable... but how do you know which global
> variables
> are available in a template?
I suppose this won't be extended that often, so it is at least solveable
by good documentation.
I still like the more explicit variants (passing one or mor structs /
objects; custom template functions) more.
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: includes and use variables
On Wed, 2007-08-29 at 15:40 +0200, Frederik Holljen wrote:
> On Wednesday 29 August 2007, Raymond Bosman wrote:
> > On Wednesday 29 August 2007 17:08, Frederik Holljen wrote:
> > > On Wednesday 29 August 2007, Raymond Bosman wrote:
> > > > > > Personally, I compare each template with a function. The {use}
> > > > > > variables are the function arguments. I think all the solutions we
> > > > > > proposed are used in one or another way in a programming language.
> > > > >
> > > > > Yes, this is what I do as well. Can you give me examples of the
> > > > > original three proposals in programming languages? The last two have
> > > > > parallels to programming languages except you don't know in which
> > > > > context your template will be called and so don't know which globals
> > > > > will be available
> > > >
> > > > Solution 1, 2, and 3 can be seen as a nested function definition.
> > > >
> > > > def template_p(a,b,c,d,e,f):
> > > >
> > > > def template_q(a):
> > > > print a
> > > >
> > > > def template_r():
> > > > print b
> > > > print c
> > > >
> > > >
> > > > Function template_p is called from the user application; thus has all
> > > > variables. template_p does an {include "template_q" send a}. That
> > > > template includes template_r. All those sub-includes have access to the
> > > > variables from the top function scope.
> > >
> > > This is not the same since the sub methods are created within the context
> > > of each other., and the variables passed implicitly are set from this
> > > context. Also, the methods are only available in the context in which
> > > they were created. This is not the case with the template definitions,
> > > they are just loose "function" definitions which can be called from
> > > anywhere.
> >
> > Okay, it is not *exactly* the same. But think about the concept. The next
> > example comes closer?
> >
> > def user_application_send(a,b,c,d,e,f):
> > def template_q(a):
> > print a
> > template_r() # {include "r"}
> >
> > def template_r():
> > print b
> > print c
> It's a bit closer since you can call a sub-method slightly out of context.
> Can
> you actually do that in python? I'm not impressed... :D
>
> It makes me think about another option though, and that is to actually add
> contexts to our templates. If you say which context the template belongs to
> then you can start doing stuff like the above. A context can be as advanced
> as you like it to be.. it can be a string.. to a full blown "template class"
> declaration with templates (functions..).
If you can't just live with passing structs and / or with (well
documented) template function which gives you access to the data, I
think this is a very nice concept.
Template contexts could be imported and give you access to a defined
(documented) set of variables...
Nice idea!
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: includes and use variables
On Thu, 2007-08-30 at 14:23 +0200, Raymond Bosman wrote:
> Hi,
>
> I added the solutions mentioned in the previous mails to the proposal. Here
> are the new solutions and a new evaluation. Please, check if it is correct.
>
> The "context" proposal is not included. Frederik or Kore can you give me an
> example? Please, keep in mind that the word "context" may be confusing
> because we use that to set the target output to: HTML or text.
Solution 9: Template contextes
--
You define some "context", or collection, I don't know a better word
yet, which aggregates several variables.
$t = new ezcTemplate();
$t->collection->foo = new ezcTemplateVariableCollection();
$t->collection->foo->a = 1;
$t->collection->foo->b = 2;
$t->process("p");
Template p and q are:
Template p:
{use $foo}
{include "q"}
Template q:
{use $foo}
{$foo->a}
{$foo->b}
The main difference is here, that you don't need to pass this
collection, but just import it in every template you want.
- This can be documented, even it is not easily user visible.
- You could use another block for this, for example {import} and not
{use} to make it even more obvious.
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template: includes and use variables
On Thu, 2007-08-30 at 14:23 +0200, Raymond Bosman wrote:
> Hi,
>
> I added the solutions mentioned in the previous mails to the proposal. Here
> are the new solutions and a new evaluation. Please, check if it is correct.
>
> The "context" proposal is not included. Frederik or Kore can you give me an
> example? Please, keep in mind that the word "context" may be confusing
> because we use that to set the target output to: HTML or text.
>
> Attached is the proposal.
>
> =
>
>
>
> Solution 6: Struct like variable passed on
> --
> The variables send to the first template can be packed in one structure. For
> example the user application sends:
>
> $t = new ezcTemplate();
> $t->send->structure = new ezcTemplateVariableCollection();
> $t->send->structure->a = 1;
> $t->send->structure->b = 2;
> $t->process("p");
>
> Template p and q are:
>
> Template p:
> {use $structure}
> {include "q" send $structure}
>
>
> Template q:
> {use $structure}
> {$structure->a}
> {$structure->b}
I still like this solution best, because you don't even need to create
something like ezcTemplateVariableCollection - you could just use some
stdObject, or some random structure defined in your application.
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquaters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Bumping PHP version requirement to 5.2
On Thu, 2007-09-06 at 15:09 +0200, Tobias Schlitt wrote: > Hi all! > > On IRC the issue occured, if we don't want to raise the required PHP > version of eZ Components from 5.1 to 5.2. My majore concern is, that it > would then be possible for Kore and me to rely on Dericks DateTime > object for parsing and representing date/time information. Having a dependency on 5.2 for Webdav would really make sense. > I think that every hoster that runs PHP 5 should have upgraded to 5.2 by > now, so it should be save for us to rely on this and refactore the > components accordingly (without breaking BC, logically). > > Opinions? Can't we introduce the 5.2 dependency components-wise? I don't like to raise the general PHP version dependency now, since most components still works quite fine with 5.1, and I am absolutely not sure how the adaption rate of 5.1 / 5.2 is... I currently do not remember, but were there any somehow breaking changes between 5.1 and 5.2, which could hindered somebody to update? If there weren't, raising the dep probably does not matter at all... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 6044 - /trunk/Webdav/src/webdav_autoload.php
Author: kn Date: Tue Sep 11 11:37:03 2007 New Revision: 6044 Log: - Fixed autoload file Modified: trunk/Webdav/src/webdav_autoload.php Modified: trunk/Webdav/src/webdav_autoload.php == --- trunk/Webdav/src/webdav_autoload.php [iso-8859-1] (original) +++ trunk/Webdav/src/webdav_autoload.php [iso-8859-1] Tue Sep 11 11:37:03 2007 @@ -38,7 +38,7 @@ 'ezcWebdavPathFactory' => 'Webdav/path_factory.php', 'ezcWebdavRequest' => 'Webdav/interfaces/request.php', 'ezcWebdavResourceTypeProperty'=> 'Webdav/properties/resourcetype.php', -'ezcWebdavResponse'=> 'Webdav/response.php', +'ezcWebdavResponse'=> 'Webdav/interfaces/response.php', 'ezcWebdavServer' => 'Webdav/server.php', 'ezcWebdavServerOptions' => 'Webdav/options/server.php', 'ezcWebdavSourceProperty' => 'Webdav/properties/source.php', -- svn-components mailing list [EMAIL PROTECTED] http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 6045 - /trunk/Webdav/src/backend/memory.php
Author: kn
Date: Tue Sep 11 11:38:13 2007
New Revision: 6045
Log:
- Added yet untested copy operation for memory backend
# Preparation to implement the actual requests
Modified:
trunk/Webdav/src/backend/memory.php
Modified: trunk/Webdav/src/backend/memory.php
==
--- trunk/Webdav/src/backend/memory.php [iso-8859-1] (original)
+++ trunk/Webdav/src/backend/memory.php [iso-8859-1] Tue Sep 11 11:38:13 2007
@@ -252,21 +252,141 @@
/**
* Copy ressources recursively from one path to another.
+ *
+ * Returns an array with ressources / collections, which caused an error
+ * during copy operation. An empty array means full success.
*
* @param string $fromPath
* @param string $toPath
- * @return void
- */
-protected function memCopy( $fromPath, $toPath )
-{
-// @TODO: Implemented
-}
-
-/**
- * Delete everything below this path
+ * @param int $depth
+ * @return array
+ */
+protected function memCopy( $fromPath, $toPath, $depth = -1 )
+{
+$causeErrors = (bool) ( $this->options->failingOperations &
ezcWebdavRequest::COPY );
+$errors = array();
+
+if ( !is_array( $this->content[$fromPath] ) ||
+ ( is_array( $this->content[$fromPath] ) && ( $depth === 0 ) ) )
+{
+// Copy a ressource, or a collection, but the depth header told not
+// to recurse into collections
+if ( $causeErrors && preg_match( $this->options->failForRegexp,
$fromPath ) )
+{
+// Completely abort with error
+return array( $fromPath );
+}
+
+// Perform copy operation
+if ( is_array( $this->content[$fromPath] ) )
+{
+// Create a new empty collection
+$this->content[$toPath] = array();
+}
+else
+{
+// Copy file content
+$this->content[$toPath] = $this->content[$fromPath];
+}
+
+// Copy properties
+$this->props[$toPath] = $this->props[$fromPath];
+
+// Update modification date
+$this->props[$toPath]['getlastmodified'] = time();
+}
+else
+{
+// Copy a collection
+$errnousSubtrees = array();
+
+// Array of copied collections, where the child names are required
+// to be modified depending on the success of the copy operation.
+$copiedCollections = array();
+
+// Check all nodes, if they math the fromPath
+foreach ( $this->content as $ressource => $content )
+{
+if ( strpos( $content, $fromPath ) !== 0 )
+{
+// This ressource is not affected by the copy operation
+continue;
+}
+
+// Check if this ressource should be skipped, because
+// already one of the parent nodes caused an error.
+foreach ( $errnousSubtrees as $subtree )
+{
+if ( strpos( $ressource, $subtree ) )
+{
+// Skip ressource, then.
+continue 2;
+}
+}
+
+// Check if this ressource should cause an error
+if ( $causeErrors && preg_match(
$this->options->failForRegexp, $ressource ) )
+{
+// Cause an error and skip ressource
+$errors[] = $ressource;
+continue;
+}
+
+// To actually perform the copy operation, modify the
+// destination ressource name
+$newRessourceName = preg_replace( '(^' . preg_quote( $fromPath
) . ')', $toPath, $ressource );
+
+// Add collection to collection child recalculation array
+if ( is_array( $this->content[$ressource] ) )
+{
+$copiedCollections[] = $ressource;
+}
+
+// Actually copy
+$this->content[$newRessourceName] = $this->content[$ressource];
+
+// Copy properties
+$this->props[$newRessourceName] = $this->props[$ressource];
+
+// Update modification date
+$this->props[$newRessourceName]['getlastmodified'] = time();
+}
+
+// Iterate over all copied collections and update the child
+// references
+foreach ( $copiedCollections as $collection )
+{
+foreach ( $this->content[$collection] as $nr => $child )
+{
+foreach ( $errnousSubtrees as $subtree )
+{
+if
[Components] File exceptions for directories.
Hi, In Base we have a bunch of those nice reusable file exceptions. Should we also use them for directories? Otherwise we would need to dublicate them... (SUMZERO) > +1 If we want to use them also for directories, perhaps we should rephrase them, because all of them contain the term "file" in the exception message, while imho the term "resource" would be better. I hope nobody relies on the exception texts, though ;) (SUMZERO for rephrasing). > ±0 -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] File exceptions for directories.
On Wed, 2007-09-19 at 12:37 +0200, Alexandru Stanoi wrote: > Kore Nordmann wrote: > > Hi, > > > > In Base we have a bunch of those nice reusable file exceptions. Should > > we also use them for directories? Otherwise we would need to dublicate > > them... (SUMZERO) > > > >> +1 > > I would also suggest to reuse them. So +1. > > > If we want to use them also for directories, perhaps we should rephrase > > them, because all of them contain the term "file" in the exception > > message, while imho the term "resource" would be better. I hope nobody > > relies on the exception texts, though ;) (SUMZERO for rephrasing). > > > >> ±0 > > > > I thought directories are also files. Resources are something else. Some > tests rely on exception messages, so these tests must be changed if > exception messages are changed. So -1. "Everything is a file" ... but is_file( 'directory/' ) results in bool:false. So the average PHP user probably has a different terminology here... > > -- > Alexandru Stanoi > eZ Components System Developer > eZ Systems | http://ez.no -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Options in static methods
Hi, While writing a public static method I came across a problem. Options or class properties are not available, because we don't have a option object accessible in the class, so I ended up with a quite huge amount of optional parameters for my method: static public function copyRecursive( $source, $destination, $depth = -1, $followSymlinks = false, $dirMode = 0775, $fileMode = 0644 ) Frederik told me, that he had the same problem some time ago, so I thought, that it is the right time to discuss it with you... Possible solutions == public static $options -- A public static property called $options in the class which contains several public static methods: > ezcBaseFile::$options->foo = 'bar'; Pro: - Easy to access by the user - Common way of setting properties Con: - No access control. $option class may be (accidently) replaced by a user. Option registry --- A registry of "static" option classes in ezcBase, like: > ezcBase::options( 'ezcBaseFile' )->foo = 'bar'; Pro: - Full control over contained option classes. Con: - Quite unintuitive. Passing option class Instead of passing several single options to a public static method, we could use some of the common simulations of named parameters, like passing an array, struct or option class to the called method: > static public function copyRecursive( $source, $destination, $depth = -1, ezcBaseFileOptions $options = null ) Pro: - Full control. - No special implementation required anywhere. Con: - Unintuitive. Summary === I don't really like any of the above solutions, neither do I like the approach of passing large amounts of (optional) paramters. Can you imagine any other nice solutions for this? -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Options in static methods
On Wed, 2007-09-19 at 15:26 +0200, Derick Rethans wrote: > On Wed, 19 Sep 2007, Kore Nordmann wrote: > > > While writing a public static method I came across a problem. Options or > > class properties are not available, because we don't have a option > > object accessible in the class, so I ended up with a quite huge amount > > of optional parameters for my method: > > > > static public function copyRecursive( $source, $destination, $depth = > > -1, $followSymlinks = false, $dirMode = 0775, $fileMode = 0644 ) > > > > Frederik told me, that he had the same problem some time ago, so I > > thought, that it is the right time to discuss it with you... > > And we already have a documented solution: > http://ez.no/ezcomponents/contributing/coding_standards#id48 Hmm, then sorry for the noise. I should know our own coding standards better ;). Even this solution is not optimal from my pov, but it has probably been discussed before, without me noticing it... a) You don't have any default values - who enforces setting the options array before you call the static method? So you may have to maintain the default values in two places, or throw an exception when the options weren't set before. b) (minor) You can only set a complete option class and no single options. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquaters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 6222 - /trunk/UnitTest/src/test/runner.php
Author: kn
Date: Thu Sep 20 13:50:41 2007
New Revision: 6222
Log:
- Reverted accidentaly introduced debugging output
Modified:
trunk/UnitTest/src/test/runner.php
Modified: trunk/UnitTest/src/test/runner.php
==
--- trunk/UnitTest/src/test/runner.php [iso-8859-1] (original)
+++ trunk/UnitTest/src/test/runner.php [iso-8859-1] Thu Sep 20 13:50:41 2007
@@ -251,8 +251,6 @@
{
require_once( $package );
$class = $this->getClassName( $package );
-
-var_dump( $class );
if ( $class !== false )
{
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 6326 - /trunk/Webdav/design/extensibility.txt
Author: kn Date: Tue Oct 2 09:54:34 2007 New Revision: 6326 Log: - Some updates and spelling # tobyS: Recheck the section: The solution -> Basics -> Hooks -> Server # Modified quite a bit there - only minor modifications everywhere else. Modified: trunk/Webdav/design/extensibility.txt Modified: trunk/Webdav/design/extensibility.txt == --- trunk/Webdav/design/extensibility.txt [iso-8859-1] (original) +++ trunk/Webdav/design/extensibility.txt [iso-8859-1] Tue Oct 2 09:54:34 2007 @@ -15,8 +15,7 @@ Webdav component. It does not affect the current design provided in design.txt, but only extends this one with design details. - -This chapte gives an overview about the state of the Webdav component while +This chapter gives an overview about the state of the Webdav component while this document is created and a high level view about the problems faced to make the presented solution necessar and a high level view about the problems faced to make the presented solution necessary. @@ -45,11 +44,11 @@ Currently the component allows to replace the backend and transport objects of a server. The inheritence tree of the transport classes is meant to reflect -client specific adjustments, which is already extensibility feature. - -The backend is completly custom implementable and must follow a certain set -finterfaces to be fully compliant with the base RFC. Backends can be extended -to add additional features, since inheritenc is not taken as a matter of +client specific adjustments, which is already an extensibility feature. + +The backend is completly custom implementable and must follow a certain set of +interfaces to be fully compliant with the base RFC. Backends can be extended to +add additional features, since inheritence is not taken as a matter of extensibility here. The server layer does not provide any extensibility features. First off, @@ -88,15 +87,14 @@ The requirements set by additional RFCs affects all layers of the Webdav component and needs to access almost any functionality. At least, hooks in -ezcWebdavTransport and ezcWebdavTransport are needed. +ezcWebdavTransport and ezcWebdavServer are needed. Custom extensions - The Webdav RFC recommends custom extensions of the protocol so we will -definitly face the issue, that we need those on our own or someone else needs -it. A typical example for such an extension is the SVN Webdav extension defined -by Apache. +definitly have to face the issue, that we need those on our own or someone else +needs it. A custom extension usually adds custom properties to existing requests/responses, which does not require any interaction at all, with the @@ -175,17 +173,17 @@ any layer. The registry knows about the hooks available throughout the component and -dispatches them centrally, if a hook is signalized to it by a layer of the -component. Each time a hook is announced by any of the layers, the registry -dispatches this information to every attached callback. Hooks can be specified -to send a number of arbitrary parameters to the attached plugin methods and can -expect a return value for further processing. +dispatches them centrally, if a hook is signalized by a layer of the component. +Each time a hook is announced by any of the layers, the registry dispatches +this information to every attached callback. Hooks can be specified to send a +number of arbitrary parameters to the attached plugin methods and can expect a +return value for further processing. A hook may have any number of callbacks from several extensions assigned, which -are processed in random number, when a hook is announced. Therefore, the plugin -developer is encouraged to perform only such manipulations on the objects -received by parameters, that are harmless for other extension and especially -the basic RFC implementation. +are processed in order of registration, when a hook is announced. Therefore, +the plugin developer is encouraged to perform only such manipulations on the +objects received by parameters, that are harmless for other extension and +especially the basic RFC implementation. --- Definition of terms @@ -201,6 +199,7 @@ be installed via tie-ins or be customly developed. The Plugin-System ensures that the component stays flexible without allowing its basic API to change and keeping other extensibility levels for different purposes. + Plugin A Plugin is a package of classes, that provides optional new functionality to be used with the Webdav component. A Plugin can be configured by the user @@ -209,6 +208,7 @@ may consist of any number of classes and must contain 1 certain Configuration-Class, that follows a specific interface and implements the Registration as well as the Initialization of the Plugin. + Plugin-Registry A single instance of the Plugin-Registry care of managing plugins and dispatching h
[svn-components] 6330 - in /trunk/Webdav: src/backends/file.php tests/backend_file_test.php
Author: kn
Date: Tue Oct 2 13:43:17 2007
New Revision: 6330
Log:
- Prevent from setting live properties
Modified:
trunk/Webdav/src/backends/file.php
trunk/Webdav/tests/backend_file_test.php
Modified: trunk/Webdav/src/backends/file.php
==
--- trunk/Webdav/src/backends/file.php [iso-8859-1] (original)
+++ trunk/Webdav/src/backends/file.php [iso-8859-1] Tue Oct 2 13:43:17 2007
@@ -42,6 +42,22 @@
protected $root;
/**
+ * Names of live properties from the DAV: namespace which will be handled
+ * live, and should not bestored like dead properties.
+ *
+ * @var array
+ */
+protected $handledLiveProperties = array(
+'getcontentlength',
+'getlastmodified',
+'creationdate',
+'displayname',
+'getcontenttype',
+'getetag',
+'resourcetype'
+);
+
+/**
* Construct backend from a given path.
*
* @param string $path
@@ -336,9 +352,13 @@
{
$storage = $this->getPropertyStoragePath( $resource, $property );
-// @TODO: We should handle some (/most?) of the live properties
-// differently.
-//
+// Check if property is a self handled live property and return an
+// error in this case.
+if ( in_array( $property->name, $this->handledLiveProperties, true ) )
+{
+return false;
+}
+
// @TODO: Get rid of serialize here. We should either store them as
// vlaid XML, or use var_export. Both make some internal serialize
// methods fpr all properties necessary.
@@ -489,8 +509,7 @@
}
// Also attach generated live properties
-$liveProperties = array( 'getcontentlength', 'getlastmodified',
'creationdate', 'displayname', 'getcontenttype', 'getetag', 'resourcetype' );
-foreach( $liveProperties as $name )
+foreach( $this->handledLiveProperties as $name )
{
$storage->attach( $this->getProperty( $resource, $name ) );
}
Modified: trunk/Webdav/tests/backend_file_test.php
==
--- trunk/Webdav/tests/backend_file_test.php [iso-8859-1] (original)
+++ trunk/Webdav/tests/backend_file_test.php [iso-8859-1] Tue Oct 2 13:43:17
2007
@@ -1360,6 +1360,48 @@
$expectedResponse,
$response,
'Expected response does not match real response.',
+0,
+20
+);
+}
+
+public function testPropPatchSetLiveProperty()
+{
+$backend = new ezcWebdavFileBackend( $this->tempDir . 'backend/' );
+
+$newProperties = new ezcWebdavFlaggedPropertyStorage();
+$newProperties->attach(
+$p = new ezcWebdavGetContentLengthProperty( '23' ),
+ezcWebdavPropPatchRequest::SET
+);
+
+$request = new ezcWebdavPropPatchRequest( '/resource' );
+$request->updates = $newProperties;
+$request->validateHeaders();
+$response = $backend->proppatch( $request );
+
+$failed = new ezcWebdavBasicPropertyStorage();
+$failed->attach( $p );
+$failed->rewind();
+
+$this->assertEquals(
+new ezcWebdavPropPatchResponse(
+new ezcWebdavResource( '/resource' ),
+new ezcWebdavPropStatResponse(
+$failed,
+ezcWebdavResponse::STATUS_403
+),
+new ezcWebdavPropStatResponse(
+new ezcWebdavBasicPropertyStorage(),
+ezcWebdavResponse::STATUS_409
+),
+new ezcWebdavPropStatResponse(
+new ezcWebdavBasicPropertyStorage(),
+ezcWebdavResponse::STATUS_424
+)
+),
+$response,
+'Expected property removing PROPPATCH response does not match real
response.',
0,
20
);
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
[Components] Graph: Behavioural change: BC break?
Hi, Jakob reported bug #11777 [1], which says, that the font configuration assigned to the x axis of a chart is not used during rendering. Instead of this the font configuration of the last axis (y axis) is used for all axis. I have a patch ready to change this behaviour, but we would lose the current behaviour, that the font sizes on both axis are always equal (which often looks "better"), which will also change the output of several test cases, but fixes the bug. The options I can see here: 1) Use different font configurations for both axis. BC break? 2) Merge font configurations before rendering. This could / would mean to use the lower maximum font size, the bigger minimum font size etc. Not sure about the other values in a usual font options class - like colors or fonts. 3) Throw an exception, when modyfying the x axis font options. I don't like this, and I am not sure how this could be done without intoducing some ugly hacks. If you see other options, please tell me. For now I am in favour of option 1), even this could be considered as BC breaking. [1] http://issues.ez.no/11777 -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Graph: Behavioural change: BC break?
On Tue, 2007-10-30 at 11:47 +0100, Alexandru Stanoi wrote: > Kore Nordmann wrote: > > Hi, > > > > Jakob reported bug #11777 [1], which says, that the font configuration > > assigned to the x axis of a chart is not used during rendering. Instead > > of this the font configuration of the last axis (y axis) is used for all > > axis. > > > > I have a patch ready to change this behaviour, but we would lose the > > current behaviour, that the font sizes on both axis are always equal > > (which often looks "better"), which will also change the output of > > several test cases, but fixes the bug. > > > > The options I can see here: > > > > 1) Use different font configurations for both axis. > > > >BC break? > > Even if it is a BC break, I think it is more logical to have different > font configurations for the axis. One axis might have a lot of divisions > than the other one, so it would be better to render it with a smaller > font size. > > So I would choose 1). > > Maybe an option which says "use the same font for all axis" would be > useful here to avoid the BC break? Yeah, but I don't see a way to introduce such an option without any hacks. :/ ... I will evaluate this further. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Rgression bug in template
Hi list, By updateing the components in a personal project I found a regression in the tempalte componente between the versions 1.1 and 1.2, and opened an issue for this: http://issues.ez.no/12322 I wonder if this is really a bug, or a intentionally introduced change? Either way it breaks quite a lot templates in my application, as I rely on this old behaviour. How should / can we proceed here? -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 7207 - in /trunk/Graph: ChangeLog src/charts/line.php src/datasets/base.php tests/data/compare/ezcGraphLineChartTest_testLineChartThickLinesPerDataSet.svg tests/line_test.php
Author: kn
Date: Mon Jan 21 13:14:23 2008
New Revision: 7207
Log:
- Implemented feature #11979: Line width configurable per data set.
Added:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartThickLinesPerDataSet.svg
(with props)
Modified:
trunk/Graph/ChangeLog
trunk/Graph/src/charts/line.php
trunk/Graph/src/datasets/base.php
trunk/Graph/tests/line_test.php
Modified: trunk/Graph/ChangeLog
==
--- trunk/Graph/ChangeLog [iso-8859-1] (original)
+++ trunk/Graph/ChangeLog [iso-8859-1] Mon Jan 21 13:14:23 2008
@@ -1,3 +1,9 @@
+1.3-alpha1 - [RELEASEDATE]
+^^
+
+- Implemented feature #11979: Line width configurable per data set.
+
+
1.2.1 - Monday 21 January 2008
^^
Modified: trunk/Graph/src/charts/line.php
==
--- trunk/Graph/src/charts/line.php [iso-8859-1] (original)
+++ trunk/Graph/src/charts/line.php [iso-8859-1] Mon Jan 21 13:14:23 2008
@@ -307,7 +307,7 @@
$data->color[$key],
$fillColor,
$yAxisNullPosition,
-$this->options->lineThickness
+( $data->lineThickness->default ?
$data->lineThickness->default : $this->options->lineThickness )
);
break;
case ( $data->displayType->default === ezcGraph::BAR ) &&
Modified: trunk/Graph/src/datasets/base.php
==
--- trunk/Graph/src/datasets/base.php [iso-8859-1] (original)
+++ trunk/Graph/src/datasets/base.php [iso-8859-1] Mon Jan 21 13:14:23 2008
@@ -75,6 +75,7 @@
$this->properties['label'] = new ezcGraphDataSetStringProperty( $this
);
$this->properties['color'] = new ezcGraphDataSetColorProperty( $this );
$this->properties['symbol'] = new ezcGraphDataSetIntProperty( $this );
+$this->properties['lineThickness'] = new ezcGraphDataSetIntProperty(
$this );
$this->properties['highlight'] = new ezcGraphDataSetBooleanProperty(
$this );
$this->properties['highlightValue'] = new
ezcGraphDataSetStringProperty( $this );
$this->properties['displayType'] = new ezcGraphDataSetIntProperty(
$this );
@@ -108,6 +109,7 @@
case 'url':
case 'color':
case 'symbol':
+case 'lineThickness':
case 'highlight':
case 'highlightValue':
case 'displayType':
Added:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartThickLinesPerDataSet.svg
==
Binary file - no diff available.
Propchange:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartThickLinesPerDataSet.svg
--
svn:eol-style = native
Propchange:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartThickLinesPerDataSet.svg
--
svn:mime-type = application/octet-stream
Modified: trunk/Graph/tests/line_test.php
==
--- trunk/Graph/tests/line_test.php [iso-8859-1] (original)
+++ trunk/Graph/tests/line_test.php [iso-8859-1] Mon Jan 21 13:14:23 2008
@@ -935,7 +935,7 @@
);
}
-public function testLineChartThickLines3d()
+public function testLineChartThickLinesPerDataSet()
{
$filename = $this->tempDir . __FUNCTION__ . '.svg';
@@ -948,6 +948,38 @@
'wget' => 231,
'Safari' => 987,
) );
+$chart->data['sample 2'] = new ezcGraphArrayDataSet( array(
+'Mozilla' => 2375,
+'IE' => 145,
+'Opera' => 804,
+'wget' => 131,
+'Safari' => 1287,
+) );
+
+$chart->data['sample']->lineThickness = 2;
+
+$chart->driver = new ezcGraphSvgDriver();
+$chart->render( 500, 200, $filename );
+
+$this->compare(
+$filename,
+$this->basePath . 'compare/' . __CLASS__ . '_' . __FUNCTION__ .
'.svg'
+);
+}
+
+public function testLineChartThickLines3d()
+{
+$filename = $this->tempDir . __FUNCTION__ . '.svg';
+
+$chart = new ezcGraphLineChart();
+$chart->options->lineThickness = 4;
+$chart->data['sample'] = new ezcGraphArrayDataSet( array(
+'Mozilla' => 4375,
+'IE' => 345,
+'Opera' => 1204,
+'wget' => 231,
+'Safari' => 987,
+) );
$
[svn-components] 7208 - in /trunk/Graph: ChangeLog src/options/line_chart.php tests/data/compare/ezcGraphLineChartTest_testLineChartNoLine.svg tests/line_test.php
Author: kn
Date: Mon Jan 21 13:17:39 2008
New Revision: 7208
Log:
- Implemented feature #12382: Enhance line chart to allow invisible lines.
Added:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartNoLine.svg
(with props)
Modified:
trunk/Graph/ChangeLog
trunk/Graph/src/options/line_chart.php
trunk/Graph/tests/line_test.php
Modified: trunk/Graph/ChangeLog
==
--- trunk/Graph/ChangeLog [iso-8859-1] (original)
+++ trunk/Graph/ChangeLog [iso-8859-1] Mon Jan 21 13:17:39 2008
@@ -2,6 +2,7 @@
^^
- Implemented feature #11979: Line width configurable per data set.
+- Implemented feature #12382: Enhance line chart to allow invisible lines.
1.2.1 - Monday 21 January 2008
Modified: trunk/Graph/src/options/line_chart.php
==
--- trunk/Graph/src/options/line_chart.php [iso-8859-1] (original)
+++ trunk/Graph/src/options/line_chart.php [iso-8859-1] Mon Jan 21 13:17:39 2008
@@ -84,6 +84,14 @@
switch ( $propertyName )
{
case 'lineThickness':
+if ( !is_numeric( $propertyValue ) ||
+ ( $propertyValue < 0 ) )
+{
+throw new ezcBaseValueException( $propertyName,
$propertyValue, 'int >= 0' );
+}
+
+$this->properties[$propertyName] = (int) $propertyValue;
+break;
case 'symbolSize':
case 'highlightSize':
if ( !is_numeric( $propertyValue ) ||
Added:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartNoLine.svg
==
Binary file - no diff available.
Propchange:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartNoLine.svg
--
svn:eol-style = native
Propchange:
trunk/Graph/tests/data/compare/ezcGraphLineChartTest_testLineChartNoLine.svg
--
svn:mime-type = application/octet-stream
Modified: trunk/Graph/tests/line_test.php
==
--- trunk/Graph/tests/line_test.php [iso-8859-1] (original)
+++ trunk/Graph/tests/line_test.php [iso-8859-1] Mon Jan 21 13:17:39 2008
@@ -1018,6 +1018,31 @@
);
}
+public function testLineChartNoLine()
+{
+$filename = $this->tempDir . __FUNCTION__ . '.svg';
+
+$chart = new ezcGraphLineChart();
+$chart->palette = new ezcGraphPaletteBlack();
+$chart->data['sample'] = new ezcGraphArrayDataSet( array(
+'Mozilla' => 4375,
+'IE' => 345,
+'Opera' => 1204,
+'wget' => 231,
+'Safari' => 987,
+) );
+
+$chart->options->lineThickness = 0;
+
+$chart->driver = new ezcGraphSvgDriver();
+$chart->render( 500, 200, $filename );
+
+$this->compare(
+$filename,
+$this->basePath . 'compare/' . __CLASS__ . '_' . __FUNCTION__ .
'.svg'
+);
+}
+
public function testBarChartDataPointColors()
{
$filename = $this->tempDir . __FUNCTION__ . '.svg';
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] Framework/MVC component
Hi, Some thoughts from me regarding the MVC stuff: 1) Routing I assume you already thought of this, but I would like to see it mentioned in the document: The routing is one of the most performance critical parts of the MVC, so that it should be completely replaceable by the user with an optimized implementation for his usecase. 2) View handling The selection of views from the controller is not defined yet, and imho also a key component. I personally see the common requirements for web applications, which may be quite a lot, but at least this should be easily possible with user extensions: - Context specific templates The controller returns something to display and it should be possible to display it in diffenrent output formats (XHTML, Mail, Text, RDF-XML, ...) Generally this could be handled by some request object passed to the viewmanager, which defines the request context. (Locales, Content-Type, ...) - "Pagelayout" definition Even in one context it is often required to get entirely different outputs, like a popup, a standard and a print view for XHTML. This could be implemented with more complex context definitions, but you may want to share some templates between the different HTML views (perhaps all, except the layout template). - User overrides of templates We do this in eZ Publish. We got a set of standard templates, and you may spcify your custom tempaltes, which override one or two tempaltes to contain custom formatting. This may be done by checking a list of user defined directories for a replacement template, or more complex rules. This is not required by the initial implementation, but still should be possible. Possible solutions: - The standard way to solve this, is a viewmanager, which just takes a view object from the controller and displays this with a defined (complex) mapping, based on context and the type of the contents of the viewObject. The viewObject may of course aggregate lots of other view objects (like the navigation, ...). This solution has two drawbacks from my POC: - It is hard to provide a really simple solution for simple applications, as this would force all stuff returned by the controllers to implement at least some interface, which would make it impossible to just provide some scalar values, etc. - The overhead by the viewmanager and the defined mapping may be noticeable, and may result in poor performance. The definition of the required mapping may look a bit complex to some users... - Just pass some (pseudo) URL to the viewmanager, like html/popup/user.tpl, which may be handled by the viewmanager, because they provide enough context information in the URL, or are just mapped to the file system, for the simple / dumb solution ;) This requires extra string parsing in the view manager, which I generally dislike, though... Drawbacks: Both solutions do not directly help with the sharing of the templates between dfferent contextes, but this could be implemented dooing some magic in the viewmanager, which may know about the context semantics, and so also knows which may be shared. Somebody found the holy grail anywhere? -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Framework/MVC component
On Tue, 2008-01-29 at 12:25 +0100, Kore Nordmann wrote: > Hi, > > Some thoughts from me regarding the MVC stuff: > > 1) Routing > > I assume you already thought of this, but I would like to see it > mentioned in the document: The routing is one of the most performance > critical parts of the MVC, so that it should be completely replaceable > by the user with an optimized implementation for his usecase. One more thing concerning rerouting: - Imho the rerouting should work on basis of a defined structure, not a generated URL. Again, my concern is speed, generating a string, and parsing it again is not really smart. - You of course need the URL regeneration basing on a set of (Controller, Action, Parameters) - at least to generate URLs in the view. The URL component of course provides this, but I still think also the URL component should be replaceable by something simpler or more complex... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Document component redesign
Hi, As shortly discussed on IRC, i still have some isses with the document component, as this one needs to be taken over by someone and the implementation has not grown that far, I summarized my changes in an updated design document, which I would like to see discussed here. Major changes: - Document classes are not used purely statically any more This makes the implementation easier and has benefits when you want to extend an existing document handler - Format conversion are annotated by interfaces and not by static methods Until now a document class had to optionally implement a set of methods for each format it could export directly. Using non static access to the classes methods we can annotate this using interfaces. This is not only cleaner, but also makes the error handling easier. You do not need to try calling some method and handle the optional exception, but can test for the interface. - Templating moved to conversions For now there was a special handling of output of documents, which optionally could use a template system to create a string from the document. This can and will be implemented as a conversion. The updated document is attached, and can be found in the svn at: http://svn.ez.no/svn/ezcomponents/experimental/Document/design/design_2.txt -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no eZ Component: Document, Design ~~ :Author: $Author: kn $ :Revision: $Revision: 7271 $ :Date: $Date: 2008-02-01 12:20:37 +0100 (Fri, 01 Feb 2008) $ Design description == ezcDocument class (abstract) This class is the base class for each implemented markup format. The extending classes are named like 'ezcDocumentHtmlDocument'. The extending classes implement the required actions to load a file or string in the respective markup and return an arbitrary structure describing the document and containing all available markup information. For each document there will be at least a conversion to the DocBook__ format. The document classes may implement additional interfaces for direct access to some converted format, if there are shortcut implementations available, like the following example shows:: Beside loading a document all document classes need to implement save() method, which returns the document serialized as a string. ezcDocumentWikiBase class ^ There may be extensions, like a basic wiki syntax parser, from the document class, which implement a set of parse helper functions for some set of markup languages. ezcDocumentConversion interface --- Interface that defines an abstract conversion class. Real conversion classes will implement conversion of the given document from one format to another. The names of that classes follow the pattern: 'ezcDocumentRstToHtmlConversion'. The main method of this abstract class, convert(), takes a document of the first format and returns a document in the other format. Both objects extend the ezcDocument class:: ezcDocumentXsltConversion ^ There are a lot of conversions which may just work on the base of an XSLT. For all those conversions an abstract ezcDocumentXsltConversion class is provided, which just takes a set of XSLT files to apply to the XML of the source document and handles the selection of a proper XSLT engine. ezcDocumentManager -- The document manager knows about the document parsers to use for each format and offers a set of static convenient methods to change the used parser for a document type, or directly create a document from a string or file. The Syntax for accessing the document manager could look like:: The document manager initiall knows about all internal formats and has them registered. ezcDocumentConversionManager This won't be implemented in the first release. While you may call the conversion directly, the conversion manager has a set of registered conversion routes and offers you direct access to the document conversions, like:: There will be an interface to overwrite default conversion routes and add or change the classes used for some conversion. ezcDocumentValidation interface --- The document classes may implement the ezcDocumentValidation, which provides the method validate( $file ), which can be used to validate an input file before trying to load it. The XML based formats will usually implement this by checking against a RelaxNG based document definition. Algorithms == Transforming XML XML documents are transformed using XSLT stylesheets and XSL extension for PHP. Tran
Re: [Components] Framework/MVC component
Hi, On Thu, 2008-01-31 at 19:49 +0100, Tobias Schlitt wrote: > Hi! > > I rephrased the document and clearified some sentences. You can find the > updated version here: > > http://schlitt.info/ez/mvctools_req.txt As said earlier I still got issues with two sections. My suggestions: View-management --- The controller returns an abstract output object, which then should be displayed by the view manager. The view manager receives the output object and the abstract request object an can decide on the base of both of them which view handler to use. Example ^^^ 1. The user requests "/some/file.pdf" 2. The controller generated the data for this. 3. The view manager receives a OutputObject with the data, and knows from the request structure, that a PDF file has been requested. The view manager now select the PDF generator as the view handler and calls the right template for the generated output object. -- SNIP -- Error handling -- During debugging it must be possible to present helpful error messages to the developer, but on a production system no errors from the MVC should be shown to the user, but the developer should be able to handle them gracefully. Errors may occur during each step of the request handling, like the following examples: - Router cannot parse request - Configured / requested controller could not be found - The view can't be rendered because of incompatible data or some template parse error Those errors cannot be handled by the controller, because they happen outside of it. A configurable default controller will be called for all error messages, so the application developer may decide to send messages, show or log the occured error. An error during the execution of this default controller will cause a "501 - Internal Server Error". As none of the given errors is meant to be displayed to the user of the application (but only to the developer) no translation possibilities for the errors need to be provided. TieIns for this default controller using the EventLog and / or Mail component for error logging would be useful. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Document component redesign
> > Using the document manager > > -- > > > > :: > > ezcDocumentManager::setFormat( 'rst', 'myCustomRstHandler' ); > > $doc = ezcDocumentManager::loadFile( 'rst', '/path/to/my.rst' ); > > > > // All errors in the RST syntax should now be magically fixed. > > echo $doc; > > Do you need to set those format tables at every request? Can lazy > initialization be used for this purpose? No, just wanted to include an example for configuring the conmversion, because it was included in the old versions examples, too. In this case I included this, because I assume, literal blocks are normally converted to , and maybe someone wants them to be converted to instead... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Document component redesign
Hi, On Fri, 2008-02-01 at 14:15 +0100, Kore Nordmann wrote: > On Fri, 2008-02-01 at 13:39 +0100, Alexandru Stanoi wrote: > > > Using the document manager > > > -- > > > > > > :: > > > ezcDocumentManager::setFormat( 'rst', 'myCustomRstHandler' ); > > > $doc = ezcDocumentManager::loadFile( 'rst', '/path/to/my.rst' ); > > > > > > // All errors in the RST syntax should now be magically fixed. > > > echo $doc; > > > > Do you need to set those format tables at every request? Can lazy > > initialization be used for this purpose? Oh, actually answered the wrong thing. In the example a custom document handler is set, to overwrite the default one from the component. So: No. :) Even there custom rules we may want to add support for lazy initialization here, too. Yes. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Framework/MVC component
Hi, On Sat, 2008-02-02 at 11:24 +0100, James Pic wrote: > Hi Kore, > > Thanks for your feedback, i agree about error-handling. > > Kore Nordmann wrote: > > As said earlier I still got issues with two sections. My suggestions: > > > > View-management > > --- > > > > The controller returns an abstract output object, which then should be > > displayed by the view manager. The view manager receives the output > > object and the abstract request object an can decide on the base of both > > of them which view handler to use. > > > > Example > > ^^^ > > > > 1. The user requests "/some/file.pdf" > > > > 2. The controller generated the data for this. > > > > 3. The view manager receives a OutputObject with the data, and knows > >from the request structure, that a PDF file has been requested. The > >view manager now select the PDF generator as the view handler and > >calls the right template for the generated output object. > > Why shouldn't the view-handler be selected by the router ? Because it is a different task, and you may want to overwrite it seperately. It also may depend on the returned content from the controller. I don't see that input and output routing have anything in common - neither the context they work in, nor any methods or similar. So I just see no sense in implementing both in one class. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[svn-components] 7335 - in /experimental/Document/src: document/rst/tokenizer.php exceptions/rst_tokenizer.php
Author: kn
Date: Mon Feb 11 11:47:24 2008
New Revision: 7335
Log:
- Removed debug code and fixed docs
Modified:
experimental/Document/src/document/rst/tokenizer.php
experimental/Document/src/exceptions/rst_tokenizer.php
Modified: experimental/Document/src/document/rst/tokenizer.php
==
--- experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] (original)
+++ experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] Mon Feb
11 11:47:24 2008
@@ -97,37 +97,6 @@
return $this->tokenizeString( file_get_contents( $file ) );
}
-protected function dumpTokenizerState( $line, $position, $tokens, $string )
-{
-$lastToken = end( $tokens );
-
-// Get last 5 token in reverse order
-$tokens = array_reverse( $tokens );
-$lastTokensString = '';
-foreach ( array_splice( $tokens, 0, 5 ) as $token )
-{
-$lastTokensString .= $token->type . ', ';
-}
-
-printf(
-"\nAt line %d char %d in string '%s'.\n",
-$line, $position, substr( $string, 0, 20 )
-);
-
-if ( $lastToken )
-{
-printf(
-"- Last token read: (%d, '%s', %d:%d)\n",
-$lastToken->type, $lastToken->content, $lastToken->line,
$lastToken->position
-);
-}
-
-printf(
-"- Last tokens in list: %s\n",
-$lastTokensString
-);
-}
-
/**
* Tokenize the given string
*
@@ -149,12 +118,8 @@
{
foreach ( $this->tokens as $token => $expression )
{
-//$this->dumpTokenizerState( $line, $position, $tokens,
$string );
-
if ( preg_match( $expression, $string, $matches ) )
{
-//echo "- Matched token $token (" . $matches['value'] .
":" . strlen( $matches['value'] ) . ")\n";
-
// A token matched, so add the matched token to the token
// list and update all variables.
$tokens[] = new ezcDocumentRstToken(
Modified: experimental/Document/src/exceptions/rst_tokenizer.php
==
--- experimental/Document/src/exceptions/rst_tokenizer.php [iso-8859-1]
(original)
+++ experimental/Document/src/exceptions/rst_tokenizer.php [iso-8859-1] Mon Feb
11 11:47:24 2008
@@ -18,9 +18,11 @@
class ezcDocumentRstTokenizerException extends ezcDocumentException
{
/**
- * Construct exception from array with XML errors
+ * Construct exception from errnous string and current position
*
- * @param array $errors
+ * @param int $line
+ * @param int $position
+ * @param string $string
* @return void
*/
public function __construct( $line, $position, $string )
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7334 - /experimental/Document/tests/document_rst_tokenizer_tests.php
Author: kn
Date: Mon Feb 11 11:38:08 2008
New Revision: 7334
Log:
- Fixed test name
Modified:
experimental/Document/tests/document_rst_tokenizer_tests.php
Modified: experimental/Document/tests/document_rst_tokenizer_tests.php
==
--- experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1]
(original)
+++ experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1]
Mon Feb 11 11:38:08 2008
@@ -47,7 +47,7 @@
/**
* @dataProvider getTestDocuments
*/
-public function testLoadXmlDocumentFromFile( $from, $to )
+public function testTokenizeRstFile( $from, $to )
{
if ( !is_file( $to ) )
{
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7333 - in /experimental/Document: src/document/rst/ tests/ tests/files/rst/tokenizer/
Author: kn Date: Mon Feb 11 11:31:10 2008 New Revision: 7333 Log: - Do not include tarinling whitespaces in texts - Split texts on multiple whitespaces Modified: experimental/Document/src/document/rst/tokenizer.php experimental/Document/tests/document_rst_tokenizer_tests.php experimental/Document/tests/files/rst/tokenizer/additional_references.tokens experimental/Document/tests/files/rst/tokenizer/blockquote.tokens experimental/Document/tests/files/rst/tokenizer/blockquote_attribution.tokens experimental/Document/tests/files/rst/tokenizer/bullet_list.tokens experimental/Document/tests/files/rst/tokenizer/bullet_list_deep.tokens experimental/Document/tests/files/rst/tokenizer/bullet_list_incorrect.tokens experimental/Document/tests/files/rst/tokenizer/citation_full.tokens experimental/Document/tests/files/rst/tokenizer/comment.tokens experimental/Document/tests/files/rst/tokenizer/deep_block_quote.tokens experimental/Document/tests/files/rst/tokenizer/definition_list_alignements.tokens experimental/Document/tests/files/rst/tokenizer/definition_list_classifier.tokens experimental/Document/tests/files/rst/tokenizer/embedded_uris.tokens experimental/Document/tests/files/rst/tokenizer/escaping.tokens experimental/Document/tests/files/rst/tokenizer/field_list.tokens experimental/Document/tests/files/rst/tokenizer/footnote_complex.tokens experimental/Document/tests/files/rst/tokenizer/footnotes.tokens experimental/Document/tests/files/rst/tokenizer/footnotes_auto.tokens experimental/Document/tests/files/rst/tokenizer/grid_tables.tokens experimental/Document/tests/files/rst/tokenizer/grid_tables_complex.tokens experimental/Document/tests/files/rst/tokenizer/hyperlink_targets.tokens experimental/Document/tests/files/rst/tokenizer/hyperlink_targets_complex.tokens experimental/Document/tests/files/rst/tokenizer/hyperlinks.tokens experimental/Document/tests/files/rst/tokenizer/inline_formatting.tokens experimental/Document/tests/files/rst/tokenizer/inline_internal_targets.tokens experimental/Document/tests/files/rst/tokenizer/line_block_indented.tokens experimental/Document/tests/files/rst/tokenizer/list_quote_paragraph.tokens experimental/Document/tests/files/rst/tokenizer/literal_block.tokens experimental/Document/tests/files/rst/tokenizer/literal_block_extra.tokens experimental/Document/tests/files/rst/tokenizer/literal_block_quoted.tokens experimental/Document/tests/files/rst/tokenizer/named_reference.tokens experimental/Document/tests/files/rst/tokenizer/non_aligned_text.tokens experimental/Document/tests/files/rst/tokenizer/option_list.tokens experimental/Document/tests/files/rst/tokenizer/option_list_complex.tokens experimental/Document/tests/files/rst/tokenizer/paragraph.tokens experimental/Document/tests/files/rst/tokenizer/simple_table.tokens experimental/Document/tests/files/rst/tokenizer/simple_tables_complex.tokens experimental/Document/tests/files/rst/tokenizer/substitutions_complex.tokens Modified: experimental/Document/src/document/rst/tokenizer.php == --- experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] (original) +++ experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] Mon Feb 11 11:31:10 2008 @@ -36,7 +36,7 @@ * * @see http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#enumerated-lists */ -const TEXT_END_CHARS= '`*_[\\]|()"\':\r\n'; +const TEXT_END_CHARS= '`*_[\\]|()"\':\\r\\n\\t '; /** * List with tokens and a regular expression matching the given token. @@ -72,7 +72,7 @@ // This should be last match ezcDocumentRstToken::TEXT_LINE => -'(\\A(?P[^' . self::TEXT_END_CHARS . ']+))', +'(\\A(?P(?: [^' . self::TEXT_END_CHARS . ']|[^' . self::TEXT_END_CHARS . '])+))', ); } Modified: experimental/Document/tests/document_rst_tokenizer_tests.php == --- experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1] (original) +++ experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1] Mon Feb 11 11:31:10 2008 @@ -61,7 +61,7 @@ // Store test file, to have something to compare on failure $tempDir = $this->createTempDir( 'rst_tokenizer' ) . '/'; -file_put_contents( basename( $to ), "assertEquals( $expected, Modified: experimental/Document/tests/files/rst/tokenizer/additional_references.tokens == Binary files - no diff available. Modified: experimental/Document/tests/files/rst/tokenizer/blockquote.tokens ===
[svn-components] 7332 - in /experimental/Document/tests: ./ files/rst/tokenizer/
Author: kn Date: Mon Feb 11 11:23:52 2008 New Revision: 7332 Log: - Added basic test result files # Some results may still be slightly wrong, but this will be shown when # implementing the parser. Added: experimental/Document/tests/files/rst/tokenizer/additional_references.tokens (with props) experimental/Document/tests/files/rst/tokenizer/blockquote.tokens (with props) experimental/Document/tests/files/rst/tokenizer/blockquote_attribution.tokens (with props) experimental/Document/tests/files/rst/tokenizer/blockquote_list.tokens (with props) experimental/Document/tests/files/rst/tokenizer/blockquote_multiple.tokens (with props) experimental/Document/tests/files/rst/tokenizer/blockquote_multiple_attribution.tokens (with props) experimental/Document/tests/files/rst/tokenizer/citation.tokens (with props) experimental/Document/tests/files/rst/tokenizer/citation_full.tokens (with props) experimental/Document/tests/files/rst/tokenizer/colons.tokens (with props) experimental/Document/tests/files/rst/tokenizer/comment.tokens (with props) experimental/Document/tests/files/rst/tokenizer/comments_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/directive.tokens (with props) experimental/Document/tests/files/rst/tokenizer/directives_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/enumerated_list.tokens (with props) experimental/Document/tests/files/rst/tokenizer/enumerated_list_deep.tokens (with props) experimental/Document/tests/files/rst/tokenizer/enumerated_list_not.tokens (with props) experimental/Document/tests/files/rst/tokenizer/escaping.tokens (with props) experimental/Document/tests/files/rst/tokenizer/field_list_indented.tokens (with props) experimental/Document/tests/files/rst/tokenizer/footnote.tokens (with props) experimental/Document/tests/files/rst/tokenizer/footnote_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/footnotes.tokens (with props) experimental/Document/tests/files/rst/tokenizer/footnotes_asterisk.tokens (with props) experimental/Document/tests/files/rst/tokenizer/footnotes_auto.tokens (with props) experimental/Document/tests/files/rst/tokenizer/grid_tables.tokens (with props) experimental/Document/tests/files/rst/tokenizer/grid_tables_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/hyperlink_targets.tokens (with props) experimental/Document/tests/files/rst/tokenizer/hyperlink_targets_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/list_quote_paragraph.tokens (with props) experimental/Document/tests/files/rst/tokenizer/literal_block_extra.tokens (with props) experimental/Document/tests/files/rst/tokenizer/literal_block_quoted.tokens (with props) experimental/Document/tests/files/rst/tokenizer/named_reference.tokens (with props) experimental/Document/tests/files/rst/tokenizer/non_aligned_text.tokens (with props) experimental/Document/tests/files/rst/tokenizer/option_list.tokens (with props) experimental/Document/tests/files/rst/tokenizer/option_list_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/simple_table.tokens (with props) experimental/Document/tests/files/rst/tokenizer/simple_tables_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/substitution.tokens (with props) experimental/Document/tests/files/rst/tokenizer/substitutions_complex.tokens (with props) experimental/Document/tests/files/rst/tokenizer/transistion.tokens (with props) Modified: experimental/Document/tests/document_rst_tokenizer_tests.php experimental/Document/tests/files/rst/tokenizer/empty.tokens Modified: experimental/Document/tests/document_rst_tokenizer_tests.php == --- experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1] (original) +++ experimental/Document/tests/document_rst_tokenizer_tests.php [iso-8859-1] Mon Feb 11 11:23:52 2008 @@ -61,7 +61,7 @@ // Store test file, to have something to compare on failure $tempDir = $this->createTempDir( 'rst_tokenizer' ) . '/'; -file_put_contents( $tempDir . basename( $to ), "assertEquals( $expected, Added: experimental/Document/tests/files/rst/tokenizer/additional_references.tokens == Binary file - no diff available. Propchange: experimental/Document/tests/files/rst/tokenizer/additional_references.tokens -- svn:mime-type = application/octet-stream Added: experimental/Document/tests/files/rst/tokenizer/block
[svn-components] 7331 - in /experimental/Document: src/document/rst/ tests/files/rst/tokenizer/
Author: kn
Date: Mon Feb 11 11:04:38 2008
New Revision: 7331
Log:
- Simplified tokenizer, everything else is now left to the parser
# Visually checked the created token lists for more files...
Added:
experimental/Document/tests/files/rst/tokenizer/bullet_list_deep.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/bullet_list_incorrect.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/deep_block_quote.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/definition_list_alignements.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/definition_list_classifier.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/embedded_uris.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/field_list.tokens (with
props)
experimental/Document/tests/files/rst/tokenizer/field_list_intended.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/hyperlinks.tokens (with
props)
experimental/Document/tests/files/rst/tokenizer/inline_formatting.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/inline_internal_targets.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/line_block.tokens (with
props)
experimental/Document/tests/files/rst/tokenizer/line_block_indented.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/literal_block.tokens
(with props)
experimental/Document/tests/files/rst/tokenizer/literal_block_notations.tokens
(with props)
Modified:
experimental/Document/src/document/rst/token.php
experimental/Document/src/document/rst/tokenizer.php
experimental/Document/tests/files/rst/tokenizer/bullet_list.tokens
(contents, props changed)
experimental/Document/tests/files/rst/tokenizer/colons.txt
experimental/Document/tests/files/rst/tokenizer/definition_list.tokens
(contents, props changed)
experimental/Document/tests/files/rst/tokenizer/empty.tokens (props
changed)
experimental/Document/tests/files/rst/tokenizer/paragraph.tokens
(contents, props changed)
experimental/Document/tests/files/rst/tokenizer/titles.tokens (contents,
props changed)
Modified: experimental/Document/src/document/rst/token.php
==
--- experimental/Document/src/document/rst/token.php [iso-8859-1] (original)
+++ experimental/Document/src/document/rst/token.php [iso-8859-1] Mon Feb 11
11:04:38 2008
@@ -22,22 +22,11 @@
const WHITESPACE= 1;
const NEWLINE = 2;
-const HEADLINE = 11;
+const BACKSLASH = 3;
-const BULLET_POINT = 21;
+const SPECIAL_CHARS = 4;
-const QUOTE = 50;
-const SINGLE_QUOTE = 51;
-const DOUBLE_QUOTE = 52;
-const ASTERISK = 53;
-const UNDERSCORE= 54;
-const ROUND_BRACKET_OPEN= 55;
-const ROUND_BRACKET_CLOSE = 56;
-const SQUARE_BRACKET_OPEN = 57;
-const SQUARE_BRACKET_CLOSE = 58;
-const PIPE = 59;
-
-const TEXT_LINE = 99;
+const TEXT_LINE = 5;
/**
* Token type
Modified: experimental/Document/src/document/rst/tokenizer.php
==
--- experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] (original)
+++ experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] Mon Feb
11 11:04:38 2008
@@ -29,37 +29,14 @@
*
* @see
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#sections
*/
-const HEADLINE_CHARS= '!"#$%&\'()*+,-./:;<=>[EMAIL PROTECTED]|}~';
-
-/**
- * Allowed character sets for table lines.
- *
- * @see
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#sections
- */
-const TABLE_CHARS = '!"#$%&\'()*+,-./:;<=>[EMAIL PROTECTED]|}~ ';
-
-/**
- * Characters to start bullet lists. Prepared for inclusion in regular
- * expression character groups.
- *
- * @see
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#bullet-lists
- */
-const BULLET_LIST_CHARS = '*+\\x{e280a2}\\x{e280a3}\\x{e28183}-';
-
-/**
- * Characters to start enumerated lists. Prepared for inclusion in regular
- * expressions.
- *
- * @see
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#enumerated-lists
- */
-const ENUM_LIST_CHARS =
'(?P\\d+|[A-Z]|[a-z]|[IVXLCDM]+|[ivxlcdm]+|#)';
+const SPECIAL_CHARS = '!"#$%&\'()*+,-./:;<=>[EMAIL PROTECTED]|}~';
/**
* Characters ending a pure text section.
*
* @see
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#enumerated-lists
*/
-const TEXT_END_CHARS= '`*_[\\]|()"\'\r\n';
+const TEXT_END_CHARS= '`*_[\\]|
[svn-components] 7330 - /experimental/Document/tests/files/rst/tokenizer/colons.txt
Author: kn Date: Mon Feb 11 10:24:55 2008 New Revision: 7330 Log: - Added testfile to test for tokenizer colon detection issues Added: experimental/Document/tests/files/rst/tokenizer/colons.txt (with props) Added: experimental/Document/tests/files/rst/tokenizer/colons.txt == --- experimental/Document/tests/files/rst/tokenizer/colons.txt (added) +++ experimental/Document/tests/files/rst/tokenizer/colons.txt [iso-8859-1] Mon Feb 11 10:24:55 2008 @@ -1,0 +1,30 @@ +.. +Ho +.. + +:: +Ho +:: + +:: +Ho + +:: + + Ho + +.. +Ho +.. + +:: +Ho +:: + +Ho +:: + +:: + + Ho + Propchange: experimental/Document/tests/files/rst/tokenizer/colons.txt -- svn:eol-style = native -- svn-components mailing list [EMAIL PROTECTED] http://lists.ez.no/mailman/listinfo/svn-components
[svn-components] 7337 - in /experimental/Document: src/document/rst/tokenizer.php tests/files/rst/tokenizer/colons.tokens tests/files/rst/tokenizer/tabulators.tokens tests/files/rst/tokenizer/tabulato
Author: kn
Date: Mon Feb 11 12:15:30 2008
New Revision: 7337
Log:
- Added tab expansion
Added:
experimental/Document/tests/files/rst/tokenizer/tabulators.tokens (with
props)
experimental/Document/tests/files/rst/tokenizer/tabulators.txt (with
props)
Modified:
experimental/Document/src/document/rst/tokenizer.php
experimental/Document/tests/files/rst/tokenizer/colons.tokens
Modified: experimental/Document/src/document/rst/tokenizer.php
==
--- experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] (original)
+++ experimental/Document/src/document/rst/tokenizer.php [iso-8859-1] Mon Feb
11 12:15:30 2008
@@ -98,6 +98,26 @@
}
/**
+ * Convert tabs to spaces
+ *
+ * Convert all tabs to spaces, as defined in:
+ *
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
+ *
+ * @param ezcDocumentRstToken $token
+ * @return void
+ */
+protected function convertTabs( ezcDocumentRstToken $token )
+{
+while ( ( $position = strpos( $token->content, "\t" ) ) !== false )
+{
+$token->content =
+substr( $token->content, 0, $position ) .
+str_repeat( ' ', 9 - ( ( $position + $token->position ) % 8 )
) .
+substr( $token->content, $position + 1 );
+}
+}
+
+/**
* Tokenize the given string
*
* The method tries to tokenize the passed strings and returns an array of
@@ -122,7 +142,7 @@
{
// A token matched, so add the matched token to the token
// list and update all variables.
-$tokens[] = new ezcDocumentRstToken(
+$newToken = new ezcDocumentRstToken(
$token,
( isset( $matches['value'] ) ? $matches['value'] :
null ),
$line,
@@ -139,6 +159,15 @@
++$line;
$position = 1;
}
+
+// Convert tabs to spaces for whitespace tokens
+if ( $newToken->type == ezcDocumentRstToken::WHITESPACE )
+{
+$this->convertTabs( $newToken );
+}
+
+// Add token to extracted token list
+$tokens[] = $newToken;
// Restart the while loop, because we matched a token and
// can retry with shortened string.
Modified: experimental/Document/tests/files/rst/tokenizer/colons.tokens
==
Binary files - no diff available.
Added: experimental/Document/tests/files/rst/tokenizer/tabulators.tokens
==
Binary file - no diff available.
Propchange: experimental/Document/tests/files/rst/tokenizer/tabulators.tokens
--
svn:mime-type = application/octet-stream
Added: experimental/Document/tests/files/rst/tokenizer/tabulators.txt
==
--- experimental/Document/tests/files/rst/tokenizer/tabulators.txt (added)
+++ experimental/Document/tests/files/rst/tokenizer/tabulators.txt [iso-8859-1]
Mon Feb 11 12:15:30 2008
@@ -1,0 +1,12 @@
+ test
+ test
+ test
+ test
+ test
+ test
+ test
+test
+ test
+ test
+a test
+ a a test
Propchange: experimental/Document/tests/files/rst/tokenizer/tabulators.txt
--
svn:eol-style = native
--
svn-components mailing list
[EMAIL PROTECTED]
http://lists.ez.no/mailman/listinfo/svn-components
Re: [Components] skip data in drawing
Hi, On Tue, 2008-05-27 at 16:12 +0200, Stanislav Zheltov wrote: > Hello, > > I’m using the Graph component and couldn’t answer the question from > documentation: > > Is it possible (if you have empty data field) not to draw it on chart, > or let’s say skip it in this column? > > Currently if you have an array with one empty value – it will be drawn > as ‘0’ on graph, though the value wasn’t there in this column If you do not want one column to be drawn in the graph, just do not set it in the provided array, as shown in the attached example. I just tested this with bar and line charts and it seems to work fine here. We could also add an option to ignore "empty" values, but you might want that values === 0 are drawn in the graph, at least in line charts. What would you consider "emtpy" values in this case? Kind regrads, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no mail_08_05_28.php Description: application/php <> signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] skip data in drawing
Hi Stanislav, On Wed, 2008-05-28 at 11:38 +0200, Stanislav Zheltov wrote: > Dear Kore, > Thank you for the reply, I didn't expect to get it so soon) > > This is a possible way around, I'll try to use it, but let's say you > want to display some results(maybe test results) and there is a > difference if the result was 0 or it wasn't tested at all (empty > value). It would be fair to draw 0 results if there is a 'zero' value > in array, but you would like to see nothing if the value is "". PHP as weakly typed language by default does not really differentiate between "" and 0, so do we here. We accept everything, which can be casted (float, int, but also strings) - which might be expected by people directly insertig stuff fetched from some database or userinput. I would suggest to filter your array before passing to the graph component. We could of course implement such a filter system in the datasets, but this seems the wrong place for me to do this. The default action of array_filter()¹ should work fine for you, to accomplish what you are looking for. Kind regards, Kore ¹ http://docs.php.net/array_filter (Example #2) -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Hi, I just copied the document from google docs, only applying some reformatting. So that the contents will definitely need some refactoring... On Fri, 2008-06-20 at 14:22 +0200, James Pic wrote: > Kore Nordmann wrote: > > - Controllers only return some view structure, which may contain semantic > > information about the data to display or information about the template to > > use. > > Did you mean: may *not*? No. The key point of dispatching the view structures in the view handler are the smatics of information returned by the controller. For example the controller may return a fooUserStructure, so that a special template could be used to display the user information. Another possible way to go is the provide some path to some template in the view structure, which would be possible, but I'd always prefer the first way, but using this both remains possible. > > - (HTTP) redirects are also "just" some view structure, which is returned by > > the controller, and the view actually performs the proper action depending > > on the context. > > Do we want the controller to set HTTP headers in the output object? > I'd say that the view-manager should take care of figuring the response code > by > itself. No, no protocol specific stuff in controller at all. The key point of this is, that the controller returns "something", and the view decides to do a redirect because of the provided view structure. The same for error codes, or whatever. > However, we might want to standardize some common UI needs, like with a list > of > user-messages or something like this: "sorry, you don't have the permission > to do > something". "Sorry, please try again later" ... This may be implemented in one of our example implementations... > > Request Parser > > == > > Filtering for common actions on every request, for example checking for > > authentication and sessions. > > Should the request parser identify the user making the request? > I though that we decided to do this in the controller. Yeah - not sure what this point is about. The request parser should of course include such relevant information in the input structure, but the actual filtering is an optional preprocessor step in the controller. > > Filters can be set on the controller, which are > > called first and work on the input - modify, action being run at all ... > > Callbacks? Or a filter configuration? How deep do we want this? Depends on the implementation. I would not want to enforce this, but we should provide an example implementation with a "complete" filter stack. > > The "user" object should be accessible in the view as well, to allow for > > anonymous/authenticated. > > Do we want a user interface or something like that? (to make the code portable > and testable) I don't think we should specify up to this point. It entirely depends on the view structures you pass back from the controller. Like the first example shows there may be big differences in what users might want there. And it is trivial to provide some application dependant user view structure. Also we said, that we want to include the (unauthorized, unvalidated) in the input strucutre, defined by the request parser and pass this structure also to the view - so the information will probably be available somehow... Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
On Mon, 2008-06-23 at 14:41 +0200, James Pic wrote: > Derick Rethans wrote: > > On Fri, 20 Jun 2008, James Pic wrote: > > > Kore Nordmann wrote: > > > > - (HTTP) redirects are also "just" some view structure, which is > > > > returned by > > > > the controller, and the view actually performs the proper action > > > > depending > > > > on the context. > > > Do we want the controller to set HTTP headers in the output object? > > > I'd say that the view-manager should take care of figuring the > > > response code by itself. > > Yes, I think this should be up to the view/view manager. > > How do we want that standartized for the output object? > Here is a short list of proposals: > - $output->status: status identifier, like OK, FAIL, REDIRECT ... > - $output->redirect: the redirect object, with variables that should be sent > and > the controllr name > - you-name-it Imho: No standard. Each view router (or how we called it) may be implemented in a way it makes sense for the respective application. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: > Hi, this is the updated current points to discuss. > Feel free to comment or add any ;) > > HTTP Request Parser > === > > Reminder: the request parser creates the abstract input object. > > 0) Should it allow plugins? > > no > 1) Should filter anything? > > no > 2) Should all the GET/POST variables be mixed together? > > yes GET variables should be used for view selection, or maybe selection of the data to display, while POST data should be used for modifications. I wouldn't like that those semantic differences between thse two data arrays are lost in the request parser. But since I am able to extend those classes / replace them this isnÄt a big issue. > 3) Should all uploaded files info be in something like $input->files? > > yes > > Input Filters > = > > 0) Should the component supply an input filter interface? > > yes > 1) Should the component supply input filters? > > yes, one in a first stage, then many with tieins > 2) Should the component user handle filtering in his controllers? > > yes > > Output Filters > == > > 0) Should the component supply an output filter interface? > > yes > 1) Should the component supply input filters? > > yes, one with HTML/Tidy in a first stage, then with tieins I don't see a real necessity for this, as told before, a charset charset encoding conversion filter could be more useful as a simple example... > 2) Should this filters be pluggable in the view-manager? > > no IF we support output filters, they must be pluggable. Hardcoded filters are imho a no-go. > 3) Should this filters be freely usable by the component user once he has his > output from the view manager? > > yes > > Routing > === > > 0) Which routed should be developped first? Url, Tree, Regexps, Assertions > (railish) ? A regexp based router is more or less trivial... > View-manager > > > 0) Should the view-manager implement the same routing system as the router? How could that work? I don't think the view routing will be URL based in most cases, but "just" based on the provided view structures. Not sure if some basic general implementation is useful here... > 1) Should another object be used to factorized processes that are common the > the input and the view-router? I don't understand, what you mean here... > View-handlers > = > > 0) Which should be the first view handler? > > PhpViewHandler, PHP being a fine templating languages - TemplateTieIn - Plain XML / JSON serialization > PhpViewHandler > -- > > 0) How should view methods be implemented? > > In factories/singletons, it should be easy to port to Template extensions I don't see a real reasoning for factories or singletons here. Just something like the following should be sufficant: > $foo->viewRouter = new myViewRouter(); Where the view router then instantiates the proper template and passes the values returned by the controller to the template and maybe also the input structure... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [Document] Wikilinks in ReST
On Tue, 2008-08-12 at 17:03 +0200, Thomas Koch wrote: > Hi Kore, > > I adapted[1] a little Wiki script to use ezcDocument. Now I wounder what > would be the best way to write Wikilinks in ReST. They should be as > short as possible and maybe even correspond to other ReST based Wikis > like MoinMoin[3] or Trac[4]. > > My personal favorite is the MoinMoin syntax: > [:HelpContents:Contents of the Help] > > Would it be possible to have a kind of hook to parse CamelCase words as > Wikilinks? There are people who like them (not me). Implementing something like this, would make us incompatible with the ReST standard [1], as such I would strongly discourage from doing so. We will implement some parser for common wiki markup at some time, which will implement some of the common wiki link syntaxes, but merging those standards does not look right to me. I would just interprete local links as wiki links, using the common syntax for anonymous links, or named references, like: > Some text with `a link`__. > > __ WikiPage You can easily change the style of those links with a custom extension of the HTML visitor, like I do in the one attached. Changing the used visitor is described in the tutorial [2]. [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html [2] http://ezcomponents.org/docs/tutorials/Document#restructured-text -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no xhtml.php Description: application/php signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Question according to piechart of ezComponents
On Mon, 2008-08-18 at 16:25 -0400, Ruslan Adigamov wrote: > Hello Kore, > > I have one question according piechart. > There is example of 'Access Statistics' in the tutorial > http://ezcomponents.org/docs/tutorials/Graph . > I'd like to know how to divide say Mozilla into sub slices (for > example version of Mozilla Firefox 1.5, 2.0, 2,1, 3.0) , set different > color for it, but leave the common label Mozilla. This is not possible until now. To implement it cleanly it would require some kind of nested dataset, or multidimensional dataset, like: > $graph->data['browser'] = new ezcGraphArrayDataSet( array( > 'Mozilla' => new ezcGraphNestedDataSet( 12, 23, 42 ), > ... > ) ); We discussed multidimensional datasets earlier for Gantt charts and Bubble charts, but never got to implement them. This is a quite an interesting topic, but I guess I won't have time for it this release cycle. You might either add a feature request to the bug tracker, and we will see when we get there, or try to implement it yourself. We have outlined the development process for external contributions to the eZ Components project here: http://ezcomponents.org/contributing/dev_process -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] GraphLineChart options: XY chart with _no_ lines
On Thu, 2008-10-02 at 17:43 +0100, Joao Ferreira gmail wrote: > Hello list, > > Is there a way to have the ezcGraphLineChart plot only the X-Y marks and > not the lines ? Yes, this is possible. You can do that by: $chart->options->lineThickness = 0; as documented here: http://ezcomponents.org/docs/api/trunk/Graph/ezcGraphLineChartOptions.html#prop-$lineThickness An example result image with this behavior can be found here: http://ezcomponents.org/docs/api/trunk/img/line_chart_phpuc.png -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Line chart
Hi Bruno, On Mon, 2008-10-13 at 14:19 +0100, Bruno Vieira wrote: > Hello all. > > I'm trying to draw a Line chart without lines, but only with the dots > on each X,Y pair. I checked here on the list for something like this > and I found a thread where it says to use the lineThickness property. > This property only allows positive numbers (minimum is 1). So, with > this one I can't have the effect I would like to have as we can see on > the image: > http://www.ezcomponents.org/docs/api/trunk/img/line_chart_phpuc.png In trunk/ and the last release the minimum line thickness is 0, you might want to update your installation. See the set method of the last released version: http://svn.ez.no/svn/ezcomponents/releases/Graph/1.3/src/options/line_chart.php Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] axis label format string
Hello Joao,
On Thu, 2008-10-16 at 18:33 +0100, Joao Ferreira gmail wrote:
> I need some way to format the string of my Y axis in a way that would
> allow me to do this
>
> Y axis tick - Label
> 1000 - 1kbit/s
> 100 - 1Mbit/s
> 10 - 1Gbit/s
>
> well, this is more of a php question really :)
This function should roughly do, what you are intending here.
function format( $number )
{
$identifier = array( 'k', 'M', 'G', 'T', 'P' );
$i = 0;
while ( ( $number > 900 ) &&
( $i <= count( $identifier ) ) )
{
$number /= 1000;
++$i;
}
return sprintf( '%.2f %sbit/s',
$number,
( $i === 0 ? '' : $identifier[$i - 1] )
);
}
> is there a way for the format string to execute some procedure defined
> by myself in order to map Y-tick values to specific strings defined by
> me ?
I don't really get what you are intending here, can you please elaborate
and explain what you are trying to accomplish?
Kind regrads,
Kore
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquarters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] setting space between Y-axis and Y-axis labels
On Thu, 2008-10-23 at 10:36 +0100, Joao Ferreira gmail wrote: > Hello list, > > I'm using "ezcGraphLineChart". > > How do I set some spacing between my Y-axis and the Y-axis labels ? You can increase the padding of the text blocks, like: > $chart->yAxis->font->padding = 1; // Or more > In some situations the labels are over the axis and I'dd like to avoid > that. Which axisLabelRenderer are you using? If I remember correctly the rotated-label-renderer ignores the padding currently. If you are using the SVG driver it might help to set a SVG font for better text size estimation: http://ezcomponents.org/docs/tutorials/Graph#glyph-support Which means, you need to convert a font into a SVG font, and just use it as the font in graph, like: > $chart->font = '/path/to/font.svg'; Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] auto fill up ezcGraphLineChart
On Sun, 2008-10-26 at 17:55 +0100, Stefan Riedel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > I 've a problem with the ezcGraphLineChart class. I have the following > array as example: > [..] > Is there a way to fill out the vacencies automaticly with the class? No, there is no way to do this with ezcGraph, but it should be quite trivial to implement in a small custom loop on your array with DateTime::modify()[1]. Kind regards, Kore [1] http://docs.php.net/manual/en/function.date-modify.php -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Horizontal Bars diagram
Hi Raul, On Tue, 2008-11-04 at 18:00 +0100, Raul Mateos wrote: > Hello! I'm new in the list. I'm using the june 2008 version under > linux (ubuntu). I have discovered these great components and trying to > use for several Open Source projects. > > I'm trying to do two things using the graph component and I have one question: > > - First is how to create an horizontal bars diagram. Is it possible? > If so, how can I do it? This is not yet possible, but we have an open enhancement request [1] for it. Until now we did not have the time to actually implement that. > - Second, How can I change the line thickness and border color for bar > diagrams? I've seen it in > http://kore-nordmann.de/blog/comparison_of_php_image_libraries_update.html In this diagram only the color of the bars have been changed. Due to slight overlapping of the semi transparent surfaces the bar borders seem to have a color, which actually is not true. You can accomplish that by setting, for example: $chart->data['dataset']->color['bar 1'] = '#A4B0' > - Third. Are there more dataSetSymbols to use in line graphs? Currently there are only the following datasymbols: - None - Bullet - Circle - Diamond You can extend those by extending the method drawSymbol() in the renderer classes - maybe even with some generic handler mechanism. If you don't want to do so yourself, you might want to add a feature request for this in our issue tracker [2]. Kind regards, Kore [1] http://issues.ez.no/IssueView.php?Id=13341 [2] http://issues.ez.no/ -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Horizontal Bars diagram
On Sat, 2008-11-08 at 20:49 +0100, Raul Mateos wrote: > Thank you Kore for your answers. > > Another question is: There is any way to put the distance between the > title and the graphic or the graphic and the legend? Sometimes they > are very close and I haven't found any attribute to do that. Each chart element, like the title and the legend, has some basic formatting properties, like padding, margin, background and border settings. So you can add some additional space around the legend using: > $chart->legend->margin = 2; Same for the title: > $chart->title->margin = 2; For more information on general chart element handling and formatting, see here: http://ezcomponents.org/docs/tutorials/Graph#chart-elements -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] transparent svg background
On Sat, 2008-11-08 at 10:57 +, Joao Ferreira gmail wrote: > On Fri, 2008-11-07 at 23:03 +0100, Julien Cochennec wrote: > > Hi every body, very simple problem here, I'm trying to get a transparent > > SVG background, which is easy to make with a real SVG file, you just > > have to erase the background color definition. > > Of course I've tried : > > > > $graph->background->background = ''; > > > > Try this: > > $graph->background->color = 'FF'; All color values are RGBA values (red, green, blue, alpha), so the last value defines the transparency of the color. Just use: > $graph->background->color = '#'; Some clients do not yet support transparent backgrounds in SVG, latest Webkit, Gecko and Opera should be fine, though. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Missing ticks in line chart
Hi, On Thu, 2009-01-15 at 12:42 +0100, Peter Hopfgartner wrote: > I'm experimenting with the graph component. Unfortunatly some ticks on > the x-axis are missing. > > I've attached a reduced test case and the result. Is this one of those > "numerical inaccuracies", as stated in > > Platform: Ubuntu 8.10, 64 bit > PHP: 5.2.6 > Graph: 1.4 > Base: 1.6 > > It happens with GD and with Cairo. > > Is there anything I am doing wrong? It is the default behavior of the labeled axis to reduce the amount of labels to a value specified in the labelCount option. You can change that using: $chart->xAxis->labelCount = count( $dataset ); You might want to consider using a different axis type, which better fits the assigned data, like a numeric axis, which is documented here: http://ezcomponents.org/docs/tutorials/Graph#axis Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Proposal: SystemProcess - External command execution component
On Wed, 2009-02-04 at 11:46 +0100, Jakob Westhoff wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Frederik Holljen wrote: > >>> Design goals > >>> > >>> The workflow of a creating a SystemProcess object applying > >>> certain arguments as well as options to it and finally spawning > >>> the process should be intuitive as possible. The best way to > >>> achieve such an intuitive API would be to design it having the > >>> fluent interface pattern in mind. The used interface should look > >>> something like this:: > >>> > >>> new ezcSystemProcess( 'echo' )->argument( 'foo' )->execute(); > >> > >> Method chaining can not be done with "new classname", so it has to > >> be: > >> > >> $p = new ezcSystemProcess( 'echo' ); $p->argument( 'foo' > >> )->execute(); > > > > I don't see why the fluent interface pattern makes this more > > intuitive. I'd say it makes it less intuitive as a command is really > > not complicated at all and the fluent interface pattern is to make a > > complicated API more intuitive to use. > > > > Consider: cmd = array( 'program_name', 'arg1', 'arg2', 'arg3', > > 'arg4', 'arg5', 'arg6', 'arg7' ) pOpbject = > > ezcSystemProcess::execute( cmd ) > > > > vs $p = new ezcSystemProcess( 'program_name' ); $p->argument( 'arg1' > > )->argument( 'arg2' )->argument( 'arg3' )->argument( 'arg4' > > )->argument( 'arg5' )->argument( 'arg6' )->argument( 'arg7' > > )->execute(); > > > > Which one is easier to read and less hassle to write? Another > > advantage of the top one is that you can easily alter one parameter > > and then run the command again. > > I agree with you, that in the case presented above the array seems to be > more readable. But as soon as arguments tend to get a little bit longer > or contain variables in my opinion the fluent interface provides much > more readability, especially with proper formatting. Also, it allows to extend the functionality with "special" arguments, which require processing, like ->pathArgument() with some applied magic to work cross different OS. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Document: PDF generationr requirements.
Hi, Find the PDF generation requirements document for the document component attached. This document offers a first discussion base for a requirements specification of PDF generation, which is on the roadmap for this release cycle. It does not involve reading PDF (which would mean converting PDF to Docbook). The design and implementation of the PDF generation will be discussed once we agreed on the requirements. Looking forward to your comments, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no === Requirements for PDF generation === Generation of PDF documents should be added to the document component. Those PDF documents should be created from Docbook documents, which can be generated from each markup available in the document component. This document summarizes the requirements for PDF generation. Central requirements The key requirements for the component Layout -- The central requirement is to generate user styles PDF documents from Docbook markup. The customized styling should include, but is not limited to: - Text - Fonts and text sizes - Line heights - Colors - Alignments - Pages - Footer and headers - Background images - Multiple text columns per page - Page sizes - Margins and paddings - Block level elements (tables, graphics, literal blocks, ...) - Borders, backgrounds, fonts, colors It must be possible to assign different styles depending on the parent elements in the Docbook markup, so that the titles in the following Docbook document can be formatted differently:: Article title First heading Second heading It would be nice if the styles can be imported and exported from / to a easily readable and writeable format. Text formatting --- Proper formatting of texts is most probably the biggest problem in the implementation, the requirements include: Hyphenation ^^^ Especially justified texts in narrow text columns requires hyphenation for words, otherwise the blanks between characters and words might increase to much. A pluggable hyphenation mechanism is required, which can be adapted to different languages, based on externally available dictionaries. Widows and orphans ^^ See: http://en.wikipedia.org/wiki/Widows_and_orphans There should be ways to configure the thresholds under which paragraphs are considered widows or orphans, which should be avoided. Inline formatting ^ Depending on the used font and styles inline formatting might have a serious effect on the text width. This MUST be respecting during text rendering. LTF and RTL languages ^ The text wrapping must be able to work with left-to-right and right-to-left languages. Floating media objects ^^ For media objects, which do not span the whole column width, it should be possible to float text around the media objects. Detection of the actual image borders is not required - the rectangular frame around the image should be sufficant for text floating. Embedding of media -- There are a lot of different media types, which might be embedded into PDF: The most common format seem to be JPEG and EPS. JPEG is not suitable for several types of graphics [1], and EPS can only be used properly for some types of vector based images. Conversion options and supported formats must be evaluated. It might depend on the used driver which formats are supported. PDI allows embedding of other PDFs inside the created PDF - this can be useful when merging different generated documents. .. [1] http://kore-nordmann.de/blog/image_formats.html Metadata The document component already preserves metadata associated with documents. PDF supports embedding additional document metadata. This should definitely be embedded, but it might also be useful to offer a easy accessible API for embedding of additional metadata. XMP is especially designed to embed metadata using the RDF. Autogenerated contents -- Headers and footers often contain some fixed texts, but might also contain autogenerated contents, like: - Current page / number of pages - Current section title - Author, read from document metadata It must be possible to define callbacks which generate those contents for the page they are currently rendered on. The best possible markup used for generation of those contents needs to be evaluated. Driver infrastructure - There are multiple ways to generate PDF documents, like: - pecl/libharu - FPDF - TCPDF - pdflib - Zend_PDF It
Re: [Components] Document: PDF generationr requirements.
On Wed, 2009-02-11 at 11:21 +0100, Nicolas Pastorino wrote: > Hi Kore, > > On Feb 10, 2009, at 15:59 , Kore Nordmann wrote: > > > Hi, > > > > Find the PDF generation requirements document for the document > > component > > attached. > > > > This document offers a first discussion base for a requirements > > specification of PDF generation, which is on the roadmap for this > > release cycle. It does not involve reading PDF (which would mean > > converting PDF to Docbook). > > > Here are some inline inputs : > * Not knowing so much about the PostScript and Latex formats, i am > wondering how far from PDF these could be, and if it would be worth > taking them into account. I guess they shall not be part of the first > implementation iteration, but having an open-enough design might help > integrating them eventually, if need be. I guess PostScript will be similar enough to be embedded just as another driver, but some further research would be required here. I think I will take a deeper look at PS in the design phase to ensure at least forward compatibility. LaTeX on the other hand does not contain explicit layouting information itself, but is just another document markup format. It should be quite easy to convert Docbook to LaTeX given the existing infrastructure. Reading LaTeX on the other hand would be really hard, since it is common to use custom packages, which are basically macros, which again are a turing complete programming language. That said a proper LaTeX reader would require to implement a "full" interpreter. Thanks for the comments & Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Document: PDF generationr requirements.
Hi Jérôme, On Wed, 2009-02-11 at 14:59 +0100, Jérôme Renard wrote: > how about PDF document protection ? > Is this something we should take into account (not necessarily for the first > releases) ? > I am quite sure we will have to following use case in a near future : > > An editor creates a document and plan to send it to someone else > but want to protect it. I remember this can be done in Adobe's software > but I do not know if this is done within the PDF file or somewhere else. > > Do you think that adding document proctection is possible in the Document > component, at least for PDFs ? If the used PDF extensions / libraries provide an API for it, we can support it and should even expose it from the very beginning, I think. I guess it shouldn't be hard to provide a unified API covering all PDF drivers - even I did not check it yet. :) Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Document: PDF generationr requirements.
On Mon, 2009-02-16 at 11:52 +, Derick Rethans wrote: > On Tue, 10 Feb 2009, Kore Nordmann wrote: > > > Find the PDF generation requirements document for the document component > > attached. > > > > This document offers a first discussion base for a requirements > > specification of PDF generation, which is on the roadmap for this > > release cycle. It does not involve reading PDF (which would mean > > converting PDF to Docbook). > > I think that I am missing the posibility to have different layouts. F.e. > for the cover, TOC, left/right pages and perhaps other sections. Different layouts are generally avaialble through the styling of elements, like mentioned in Central requirements > Layout. Left/right pages specific layouting is only required for autogenerated contents like footnotes and page headers, I think. Those information will be available to the content generators, even I am still not sure how to really implement those. For the cover I think the discussed integration of pages from other PDF documents is the most usable way. Maybe we can make this an optional call from the content generators. A default title document can always be generated from the available metadata in the document, with custom styles given by the layout directives mentioned above. The table of contents is another of those auto-generated blocks. I will update the requirements document to clarify on those items. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] PDF generation - design document
Hi,
After we discussed the requirements during the last two weeks with no
major changes, I wrote a design document for the PDF generation. Please
ensure to find your usecases covered in the attached design document
[1].
Comments on the current design and aspects of the implementation are now
also welcome.
Kind regards,
Kore
[1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquarters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
k...@ez.no | eZ systems | ez.no
==
Design document for PDF generation
==
:Author: kn
This is design document for the PDF generation in the eZ Components document
component. PDF documents should be created from Docbook documents, which can
be generated from each markup available in the document component.
The requirements which should be designed in this document are specified in
the pdf_requirements.txt document.
Layout directives
=
The PDF document will be created from the Docbook document object. It will
already contain basic formatting rules for meaningful default document layout.
Additional rules may be passed to the document in various ways.
Generally a CSS like approach will be used to encode layout information. This
allows both, the easily readable addressing of nodes in an XML tree, like
already known from CSS, and humanly readable formatting options.
A limited subset of CSS will be used for now for addressing elements inside the
Docbook XML tree. The grammar for those rules will be::
Address ::= Element ( Rule )*
Rule::= '>'? Element
Element ::= ElementName '.' ClassName
ClassName ::= [A-Za-z_-]+
ElementName ::= XMLName* | '*'
* XMLName references to http://www.w3.org/TR/REC-xml/#NT-Name
The semantics of this simple subset of addressing directives are the same as in
CSS. A second level title could for example then be addressed by::
section title
The formatting options are also mostly the same as in CSS, but again only
using a subset of the definitions available in CSS and with some additional
formatting options, relevant especially for PDF rendering. The used formatting
options depend on the renderer - unknown formatting options may issue errors
or warnings.
The PDF document wrapper class will implement Iterator and ArrayAccess to
access the layout directives, like the following example shows::
$pdf = new ezcDocumentPdf();
$pdf->createFromDocbook( $docbook );
$pdf->styles['article > section title']['font-size'] = '1.6em';
Directives which are specified later will always overwrite earlier directives,
for each each formatting option specified in the later directive. The
overwriting of formatting options will NOT depend on the complexity of the
node addressing like in CSS.
Importing and exporting layout directives
-
The layout directives can be exported and imported to and from files, so that
users of the component may store a custom PDF layout. The storage format will
again very much look like a simplified variant of CSS::
File ::= Directive+
Directive ::= Rule '{' Formatting* '}'
Formatting ::= Name '=' '"' Value '"' ';'
Name ::= [A-Za-z-]+
Value ::= [^"]+
Importing and exporting styles may be accomblished by::
$pdf->styles->load( 'styles.pcss' );
List of formatting options
--
There will be formatting options just processed, like they are defined in CSS,
and some custom options. The options just reused from CSS are:
- background-color
- background-image
- background-position
- background-repeat
- border-color
- border-width
- border-bottom-color
- border-bottom-width
- border-left-color
- border-left-width
- border-right-color
- border-right-width
- border-top-color
- border-top-width
- color
- direction
- font-family
- font-size
- font-style
- font-variant
- font-weight
- line-height
- list-style
- list-style-position
- list-style-type
- margin
- margin-bottom
- margin-left
- margin-right
- margin-top
- orphans
- padding
- padding-bottom
- padding-left
- padding-right
- padding-top
- page-break-after
- page-break-before
- text-align
- text-decoration
- text-indent
- white-space
- widows
- word-spacing
Custom properties are:
text-columns
Number of text text columns in one section.
page-size
Size of pages
page-orientation
Orientation of pages
Not all options can be applied to each element. The renderer might complain on
invalid options, depending on the configured error level.
Special layout elements
===
Footers & Headers
-
Footnotes
Re: [Components] PDF generation - design document - CSS parser
On Tue, 2009-02-24 at 11:40 +0100, Thomas Koch wrote: > Hi Kore, > > is it right, that for this approach, you'll need a parser for the > simplified CSS? If yes, could this parser be an independent component, > that could later be enhanced to parse regular CSS? Not really, because a) Real CSS is *far* more complex to parse then the simplified grammar I used in the design document. That's why I defined a custom EBNF in the first place. b) We do not want cross component dependencies and the PCSS parsing is viable to the functionality of the component. c) I personally do not see a real usecase for CSS parsing in web applications, but prove me wrong on this. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
On Tue, 2009-02-24 at 11:49 +0100, Alexandru Stanoi wrote: > Kore Nordmann wrote: > > Hi, > > > > After we discussed the requirements during the last two weeks with no > > major changes, I wrote a design document for the PDF generation. Please > > ensure to find your usecases covered in the attached design document > > [1]. > > > > Comments on the current design and aspects of the implementation are now > > also welcome. > > > > Kind regards, > > Kore > > > > [1] http://svn.ez.no/svn/ezcomponents/trunk/Document/design/pdf_design.txt > > > Regarding pdf sets: I think other document types should be supported to > be added to a pdf, especially images. It is common to take a few TIFF or > PNG files and create a PDF out of them. You are expected to extend from the PdfDocument class for custom stuff you want to add to a PDF set. This can also be some autogenerated bibliography or index. All classes which extend from ezcDocumentPdf and follow its interface should be able to be added to a PdfSet and do whatever they like to do - maybe handling images, like you mentioned. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PDF generation - design document
On Tue, 2009-02-24 at 10:58 +, Derick Rethans wrote: > On Tue, 24 Feb 2009, Kore Nordmann wrote: > > > After we discussed the requirements during the last two weeks with no > > major changes, I wrote a design document for the PDF generation. Please > > ensure to find your usecases covered in the attached design document > > [1]. > > > > Comments on the current design and aspects of the implementation are now > > also welcome. > > We should have some form of possibility to control the width of table > columns. This has to be done for each table specially, so that means > we'd need PCSS ID support. Will add ID based addressing of document elements to the PCSS grammar - just like they are implemented in CSS. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] GRAPH - Use carriage returns in graph titles
Hello Raul, On Thu, 2009-04-30 at 14:43 +0200, Raul Mateos wrote: > Hi! > > Does any one know how to include a carriage return in graph titles? Explicit line breaks are not possible (yet) in graph. The text fitting algorithm in the driver base class does not allow this. Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Graph: Bug #15095
Hi, There is Bug #15095, which reports that a bar might interfere with the y-axis, which is reproducible here. The problem now is: The behaviour is entirely "correct", and it would require a rotatedBoxedAcisLabelRenderer to properly "fix" this problem for this use case. To explain that: The positiong of the x axis labels and steps is correct for common line charts. Moving them inwards would look strange - and break BC. Bars can only be drawn "around" steps for normal axisLabelRenderer, the boxedAxisLabelRenderer offers a better bar-chart-specific rendering algorithm, which "fixes" this, but does not implement rotated labels. I don't see a sane fix for this, except for a combination of the boxed and rotated axis label renderer to a new axis label renderer (like mentioned above). This would be a feature addition, which I would like to postpone after the release - on the other hand the current behaviour is wrong in terms of the rendered result. And there is no trivial workaround for labeled axis (Except for null values at the beginning of the data set). Two choices: 1) Implement the new renderer and add it, even we are in RC1 now. 2) Leave the bug open until after the release. -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [Graph] Bug in LineChart??
On Wed, 2009-10-14 at 09:26 +0200, Raul Mateos wrote: > Hello! > > I've tried to create a LineChart with this code: > [snip] > > And when I get the image, I can't see line or text for february and > june!! I've tried only 11 months and add a 13th element and it is > shown perfecftly, could be a bug when the number of elements is 12?? ezcGraph reduces the number of labels by default, so that not too many labels clutter the xAxis on a labeled axis. You can change this behaviour using: $graph->xAxis->labelCount = count( $graph->data['2008'] ); You might want to consider using a DateTimeAxis for datetime values. Kind regards, Kore Find more details here: - http://ezcomponents.org/docs/tutorials/Graph#lots-of-bars - http://ezcomponents.org/docs/tutorials/Graph#date-time-axis -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] labels on ezcGraphHorizontalBarChart
On Sun, 2009-11-22 at 11:12 +0100, Christof Kluß wrote: > Hello, > > in the current alpha version there are horizontal bar graphs: > > http://www.ezcomponents.org/docs/api/trunk/Graph/ezcGraphHorizontalBarChart.html > > with $chart->data['test']->highlight = true; the exact values can be > displayed at the bar. > > Is it possible to change the position of these values? So that for > example they are standing on the bar or next to the middle of the bar? [...] I see three options here: 1) There was a user contribution to configure a global offset for highlight values, which was undocumented until about 10 minutes ago (so it is not yet visible in the online documentation). You can configure a relative movement for those labels, but not their exact position in the chart, like: $chart->options->highlightXOffset = -10; 2) You can render an additional axis (at any point in the chart), which itself consists of labels, and therefor renders an additional set of labels in the charting area. This feature is documented in the tutorial to some basic extend: http://ezcomponents.org/docs/api/trunk/introduction_Graph.html#additional-axis-markers 3) If you clearly know hot to render the labels in your case you can extend from the renderer you already use and overwrite the method drawDataHighlightText() to do what you think works best. This is most flexible solution, but requires to gain some insight in the rendering infrastructure. Afterwards you can use your custom renderer as simple as: $chart->renderer = new myRenderer(); Kind regards, Kore -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [graph] Confused about labels
Hi, On Tue, 2009-11-24 at 18:01 +0100, Raul Mateos wrote: > Hello, I'm using 2009.2 beta. > > I have some data like: > > 'Jan'=>20.000, > 'Feb'=>50.000, > 'Mar'=>12.500, > ... > > an so on. > > I tried to set: > > $graph->yAxis->max = 20.000; > $graph->yAxis->min = 0; > > and I have: > > $graph->data['data']->highlight = true; > > But I get, in the y axis, the number "20" as the maximum, not "20.000" > > I've tried several axisLabelRenderer, but no luck. Also tried > $graph->options->label = '%2$.3f (%3$.1f%%) '; You can format the axis label using the axis formatString options, like: $graph->yAxis->formatString = '%.3f'; Which will format the axis labels, like you seem to expect from your examples. You are aware that in PHP the . is not the thousands separator, but a decimal point, right? :) 20.000 equals 20. here. If you want to format the axis values with locale specific numbers, you might want to try defining a custom labelCallback [1] and using the PHP function number_format() for this. Kind regards, Kore [1] http://ezcomponents.org/docs/api/trunk/Graph/ezcGraphChartElementAxis.html#prop-$labelCallback -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 k...@ez.no | eZ systems | ez.no signature.asc Description: This is a digitally signed message part -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
