Updates about Enhanced Database Ranges.

[Akash Shetye]

Hello,

Progress so far is.
+finally finished with import of column and row formatting data for tables.
+progressing on exporting back to ooxml.

Need to code faster since i am behind schedule. But I think I can cope up
well. This week by thursday you should see export feature for ooxml in
place.
On Jun 4, 2013 1:15 AM, "Markus Mohrhard" <markus.mohrhard at googlemail.com>
wrote:

> Hey Akash,
>
> 2013/6/2 Akash Shetye <shetyeakash at gmail.com>:
> > Hey devs,
> >
> > Thank you moggi and kohei for helping me out on the IRC constantly.
> >
> > With the design I am describing now, the feature becomes an n-ternating
> (not
> > alternating) row formatting (not just colouring) feature. Please help
> with
> > your advice and discussions.
> >
> > The feature design can be compartmentalised as follows:
> > 1. The 'Row Formatting definition' part, where used selects the targeted
> > database range and the styles to be applied to it.
> > 2. The 'Row Formatting core' where DB Range code and this feature
> interact.
> > 3. The rendering end.
>
> After reading this I think we need to split the task into smaller and
> easier to handle steps. Hopefully it helps us to focus on the
> important tasks for now. I'll explain some of the problems with your
> proposal below but the general point is that we should work on the
> model right now. Don't think about anything redering related, updating
> references or similar stuff until we have implemented the model and
> maybe have the import and export implemented. The visual
> representation of the feature is something that we can later add but
> is of less importance than you think right now.
>
> >
> > Row Formatting definition:
> >
> > [Data Structures]
> >
> > About the storage of this formatting information and how alternating
> > formatting info will be defined:
> >
> > User defines each alternating format as a band, and as such 'n' number of
> > bands constitute particular n-ternating format. The user select the
> > formatting options and the size of the band i.e, how many consecutive
> rows
> > it will cover/applied to. When the user defines another band, the new
> band
> > will follow the previously defined band. Thus we can have more than just
> > alternating colours for our DB ranges. Eg. define first band of size 1
> and
> > bold text, band 2 of size 3 italic text and band 3 of size 1 underlined
> > text; for a range of 10 rows, the first will be bold followed by 3 italic
> > rows followed by 1 underlined row and so on..
> >
> > Every defined band for an Alternating row format will be stored as a
> > ScDBDataRowFormat that will have the attributes: 1. index number which
> helps
> > define the sequence of these bands 2. band size 3. Formatting information
> > (ScStyleSheet instance??). It has its method GetStyle() that returns the
> > style to be applied
>
> Let us limit ourself for now to 2 alternating styles. Extending this
> later is easier than trying to implement everything at once.
>
> >
> > Many such ScDBDataRowFormat instances are added to a container which is a
> > part of ScDBDataRowFormatting object. This object represents the total
> style
> > you have created and also contains the defined style name you give to it.
> >
> > All such defined styles are added to a pool of ScDBDataRowFormatting
> > objects; lets say this pool is represented by
> > ScDBDataRowFormattingCollection (the names are getting scarily long), so
> > styles once custom defined can be used again and again.
> >
> > Associating every ScDBData object with it's ScDBDataRowFormatting object:
> >
> > Every ScDBData object has an attribute of type ScDBDataRowFormatting
> which
> > is assigned to it by picking it up from the
> ScDBDataRowFormattingCollection
> > pool.
> > Thus many DB Ranges can use the same style without having to have any
> > multiple copies to themselves.
>
> That design is overcomplicated and lacks some of the important
> features. We need at least the following features: two column styles,
> two row styles, information about header row, total row, column
> labels, ... Please have a look at Excel to see some of the information
> we need to store in data structures. A good starting point for the
> design is to list all the information we need to store for each table.
> Starting with the list we will then decide for each information how to
> represent it and how they interact and influence each other.
>
> Just a short note: When you think about styles in Calc's core
> implementation please always think only about the style name.
> Everything that is hidden behind ScDocument should at least for you
> only use the style name and never the ScStyleSheet object. If there is
> ever a case where we need access to the full style we will need to
> look closer into it.
>
>
> >
> > Row Formatting Core:
> >
> > The row formatting core is composed of the modifications needed in
> ScDBData
> > itself to support the new alternating colour functionality.
> >
> > ScDBData will have a new method GetRowFormatting() just like the one in
> > conditio.cxx (GetData()); however this will return a
> ScDBDataRowFormatting
> > object.
> >
> > The rendering half will have to iterate over each row of the the range
> while
> > iterating over the ScDBRowFormat items in the container in
> ScDBRowFormatting
> > instance taking care of the band size of each and thus applying it to the
> > row cells accordingly. This makes the rendering code a little more
> > complicated as multiple styles have to be related to different rows.
> >
> > Events (not actually events) in ScDBData such as:
> >
> > UpdateMoveTab - changes the table
> > UpdateReference()
> > ExtendDataArea - extends/shrinks the area under ScDBData
>
> Don't worry about them right now. We will come back to them when we
> have implemented all the data structures and the import/export.
>
> >
> > make changes to the structure and coverage of the defined database
> range. We
> > need to take care of such events that may wipe out or add newer rows to
> the
> > range. Such updates set the bModified bool in ScDBData, this needs to be
> > known and be handled by the rendering half of this feature.
> >
> > The rendering end:
> >
> > This rendering end is the something I am discovering with each passing
> day.
> > Not much to write here.
> >
> > Some design issues:
> >
> > I see one big problem with the way this are laid out now. The formatting
> > information and ScDBData's bounds (i.e its rows) are very decoupled. It
> > becomes the job of the rendering end to apply the correct formatting by
> > iterating over the ScDBRowFormatting container and getting the
> ScDBRowFormat
> > objects taking care of their band sizes as it moves over each row adding
> in
> > the formatting information.
> >
> > This makes the rendering end very complicated (maybe). Since rendering is
> > not just taking the concerned rows and style and shoving in the
> attributes.
> > One way out can be having a member function in ScDBData that returns an
> > array of  size[No.OfRows], each entry containing the applicable
> stylesheet
> > for that row. This shifts the 'making sense of' part, out of the
> rendering
> > part.
>
> Don't think about the rendering right now. This will be much simpler
> than you expect and all most of the logic that you think belongs into
> the rendering part actually is part of the mode and we will need it
> also for other parts of the mode implementation. In the end we will
> just have a method that returns the style name for a cell and not much
> more. But please don't worry about that right now because in the end
> you'll see that this will look just natural after all other parts are
> implemented.
>
> >
> > [UI Stuff]
> > Speaking of what to call this functionality and where to place it in the
> > menu hierarchy:
> > Either we can:
>
> That is even one step past the implementation of the rendering. We'll
> work with the UX team when we are ready to come up with a mock-up for
> the UI parts.
>
> >
> > Greet the user with the same dialog as seen in Calc's Data->Select Range,
> > from where the user selects a range to be formatted as table i.e,
> coloured
> > alternately.
> > Or, since clicking format as table option in MS Excel marks a bunch of
> cells
> > as a table with a name, which 'optionally' can be coloured; we will need
> to
> > incorporate the alternate colouring option in the Data -> Define Range
> > dialog in its 'more' section.
> >
> > In any case once this option is clicked, the user must define a custom
> > design or choose from a few existing ones, just like in Excel.
> >
>
>
> So let us split the task into several smaller steps that we tackle and
> where you should not worry about the next step.
>
> 1.) Model data structures
> 2.) Import/export (OOXML and ODF)
> 3.) Rendering and user interaction
> 4.) UI
>
> So for now we concentrate on how to implement all the model data
> structures. Mainly how we can represent all the information we need in
> calc's core implementation and let them work together. As first step
> please list all the information we need to store in the model and we
> will discuss on IRC how to represent them.
>
> Regards,
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130708/de13e16d/attachment.html>