/*
Copyright 2006,2008 Stefano Chizzolini. http://clown.stefanochizzolini.it
Contributors:
* Stefano Chizzolini (original code developer, http://www.stefanochizzolini.it)
This file should be part of the source code distribution of "PDF Clown library"
(the Program): see the accompanying README files for more info.
This Program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later version.
This Program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY, either expressed or implied; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the License for more details.
You should have received a copy of the GNU General Public License along with this
Program (see README files); if not, go to the GNU website (http://www.gnu.org/).
Redistribution and use, with or without modification, are permitted provided that such
redistributions retain the above copyright notice, license and disclaimer, along with
this list of conditions.
*/
using it.stefanochizzolini.clown.files;
namespace it.stefanochizzolini.clown.objects{
/**
<summary>This is the base high-level representation of a strongly-typed PDF object.
All specialized objects (e.g. Document, Page, Pages, ContentStream...)
inherit from it.</summary>
<remarks>
<para>Somebody may wonder why I didn't directly make specialized objects
inherit from their low-level counterparts (e.g. Page : PdfDictionary,
ContentStream : PdfStream and so on): that could have been much smoother
anyway, you argue. Yeah, I could agree if there was a plain one-to-one
mapping between primitive PDF types and specialized instances, but (you know!)
reality is not so polished as theory: the 'Content' entry of Page dictionaries
may be a simple reference to a PdfStream or a PdfArray of references to
PdfStream-s, Pages collections may be spread across a B-tree instead of a flat
PdfArray etc. So: <i>in order to hide all these annoying inner workings, I
chose to adopt a composition pattern instead of the apparently-reasonable (but
actually awkward!) inheritance pattern</i>. Nonetheless, users are always
enabled to navigate through the low-level structure accessing the
<see cref="BaseObject"/> and <see cref="BaseDataObject"/> underlying properties.</para>
</remarks>
*/
public abstract class PdfObjectWrapper<TDataObject>
: PdfObjectWrapper
where TDataObject : PdfDataObject
{
#region dynamic
#region fields
private TDataObject baseDataObject;
#endregion
#region constructors
protected PdfObjectWrapper(
File context,
TDataObject baseDataObject
) : this(
context.Register(baseDataObject),
null
)
{}
/**
<param name="baseObject">Base PDF object. MUST be a <see cref="PdfReference"/>
everytime available.</param>
<param name="container">Indirect object containing the base object.</param>
*/
protected PdfObjectWrapper(
PdfDirectObject baseObject,
PdfIndirectObject container
) : base(
baseObject,
container
)
{}
#endregion
#region interface
#region public
/**
<summary>Gets the underlying data object.</summary>
*/
public TDataObject BaseDataObject
{
get{return baseDataObject;}
}
public override PdfDirectObject BaseObject
{
get
{return base.BaseObject;}
protected set
{
base.BaseObject = value;
baseDataObject = (TDataObject)File.Resolve(value);
}
}
#endregion
#endregion
#endregion
}
}
|