14 Dec
2009
14 Dec
'09
1:24 p.m.
On Dec 14, 2009, at 1:11 PM, Vincent Massol wrote:
On Dec 14, 2009, at 12:23 PM, Thomas Mortagne wrote:
^^^^^
getCurrentModelDocumentName()
Also I missed this one:
List<AttachmentName> getAttachments(DocumentName documentName)
throws Exception;
==> getModelAttachments
WDYT?
-Vincent
On Mon, Dec 14, 2009 at 11:45, Vincent Massol
<vincent(a)massol.net>
wrote:
We also have in DAB:
DocumentName getDocumentName(String documentName);
DocumentName getCurrentDocumentName();
So I'd also propose:
DocumentName getModelDocumentName(String documentName);
DocumentName getModelCurrentDocumentName();
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
- AttachmentNameSerializer
- AttachmentNameFactory
On Mon, Dec 14, 2009 at 09:19, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Dec 13, 2009, at 1:36 PM, Vincent Massol wrote:
>
>> Before voting please consider that this will break a lot of
>> existing
>> code which is currently using org.xwiki.bridge.DocumentName
>> (since
>> it would now be named org.xwiki.model.DocumentName).
>>
>> Do we want to keep org.xwiki.bridge.DocumentName (and all the
>> others
>> too) and deprecate them?
>>
>> IMO it depends if we agree that 2.2 will introduce the new
>> model or
>> not.
>>
>> WDYT?
>
> Note that I have now finished the refactoring locally and I'm
> waiting
> for a decision. FYI there are 93 files impacted but most are
> tests or
> files which don't expose APIs. In term of APIs there are probably
> something like 20 methods whose signature have changed (mostly
> from
> org.xwiki.bridge.DocumentName to org.xwiki.model.DocumentName).
>
> For developers it means replace "bridge" by "model" in imports.
> This
> is not a big change but it means they need to re-release whatever
> "extensions" they have done (if they used the bridge) when they
> move
> to XE 2.2.
>
> Personally I don't see any way of moving forward for the new model
> without breaking some backward compat and the bridge was always
> flagged as being temporary so I'm +1 to go ahead. I'd also like to
> continue working on the model in the 2.2 timeframe to ensure that
> what
> we release for 2.2 final will be stable (for example by
> introducing
> the WikiResourceName discussed in the other mail thread on the new
> model).
I really don't like breaking API if it's not absolutely necessary
and
temporary or not bridge is public API, temporary does not mean
suddenly vanish for no reason... I don't see why adding the new
model
would have to break the bridge, that's two different things for
me and
bridge should not be broken if there is not technical issue to
keep it
working. For things other than the bridge it's ok for me since it's
more SPIs than APIs and i doubt anyone except us (or even any of
our
plugins) are using it.
For example there is not reason to delete
org.xwiki.bridge.AttachmentNameSerializer,
org.xwiki.bridge.AttachmentNameFactory,
org.xwiki.bridge.DocumentNameFactory,
org.xwiki.bridge.DocumentNameFactory, ... And we just need to
double
methods in DocumentAccessBridge dealing with DocumentName to add
methods using the new model.DocumentName if we need some.
+1 for the new model but -1 to break anything in the bridge
public API
since it's very easy to not break it.
ok I've checked more precisely what were the APIs that are broken
and
for which we could want to maintain backward compat (I have not
listed
internal implementation classes):
1) xwiki-bridge:
- DocumentAccesssBridge
- DocumentModelBridge
- DocumentNameFactory
- DocumentNameSerializer
2) xwiki-core:
- XWikiDocument (for getDocumentName())
3) xwiki-openoffice:
- XDOMOfficeDocumentBuilder
- XHTMLOfficeDocumentBuilder
- TargetPageDescriptor
- XDOMOfficeDocumentSplitter
4) xwiki-macro-wikibridge
- WikiMacroManager
- WikiMacroFactory
5) xwiki-url
- XWikiAttachmentURL
- XWikiDocumentURL
So here's what I propose:
- We keep backward compat for 1) and 2)
+1 for backward compatibility here, not sure we need aspects here
since it basically mean put almost the whole module in aspects
- We don't keep backward compat for 4) (I
doubt it's used by anyone
else and the backward compat has already been broken for that
module a
week ago) and for 5) (it's not used yet)
+0.5 for no backward compatibility here
- I'm hesitating for 3). We could keep
backward compat to make it
easier for some projects. Thus I'm slighty in favor of keeping
backward compat for it.
Not sure either. I would be more in favor of keeping backward
compatibility as a general good rule when possible.
- We use aspects whenever we want to keep
backward compat
- We need a new method name in DocumentModelBridge to add in
addition
of getCurrentDocumentName(). I don't have a good idea:
getDocumentName2(), getNewDocumentName(), getDocumentNameModel(),
getDocumentNameFromModel(), etc. Any idea?
getModelDocumentName() ? WDYT?
Thanks
-Vincent
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>>>>> On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> New proposal:
>>>>>> Create a new xwiki-model and move "clean" classes from
xwiki-
>>>>>> bridge
>>>>>> into it. These are:
>>>>>> - *AttachmentName*
>>>>>> - *DocumentName*
>>>>>>
>>>>>> Here's my +1
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>> On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne
>>>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>>>> On Wed, Aug 26, 2009 at 18:00, Vincent
Massol<vincent(a)massol.net
>>>>>>> >
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Since we have some final classes (final in the sense with
a
>>>>>>>> good
>>>>>>>> architecture) in xwiki-bridge I'd like to rename it
into
>>>>>>>> xwiki-
>>>>>>>> model
>>>>>>>> so that we can start this model module.
>>>>>>>>
>>>>>>>> Note: We'd still have a org.xwiki.model.bridge
package for the
>>>>>>>> time
>>>>>>>> being in that xwiki-model module.
>>>>>>>>
>>>>>>>> Here's my +1
>>>>>>>
>>>>>>> I would prefer to create a new xwiki-model with only the
clean
>>>>>>> apis
>>>>>>> instead of having clean and bridge in the same project.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent