[
http://jira.magnolia-cms.com/browse/MAGNOLIA-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grégory Joseph updated MAGNOLIA-2872:
-------------------------------------
Description:
There are some places in the Link api that could be improved; the methods
exposed by LinkFactory are inconsistent, for instance. (some of the methods
take String parameters and fetch a node in the repository from that, others
take a node - as a consequence, client code (or LinkFactory itself) gets messy
- on some occasions, it has to use both methods, and exception handling gets
messy, too. The fetching of nodes should be entirely handled by either
LinkFactory itself - or the client code.
One example is at {{createLink(String uuid, String repository, String
fallbackHandle, String nodeDataName, String extension, String anchor, String
parameters)}}
There are other little quirks of the same sort that could use a little
review/cleanup/rename - think testability and separation of concerns.
Also see MAGNOLIA-2259 - the solution to that issue introduced the usage of
some jackrabbit API, which we should avoid.
Additionally, we should remove/review usage of deprecated classes
({{info.magnolia.cms.link.*}}) in our own code!
Some context:
{{info.magnolia.module.fckeditor.dialogs.FckEditorDialog#convertToView}} and
its usage of {{info.magnolia.link.LinkUtil#convertLinksFromUUIDPattern}} - this
is a usecase where you don't want the exceptions to bubble up. The input might
have multiple links, and depending on the use case (editor, rendering, ...) one
might want to render the "broken" links (i.e {{<a href="/fallbackHandle">my
link</a>}}) or just the link description ({{my link}}, no surrounding {{<a>}}),
or let an exception be thrown at the first broken link. (this is not something
the api is currently target for, since {{LinkTransformer}} does not take html
into account, and {{Link}} does not have a notion of it's content/description)
was:
There are some places in the Link api that could be improved; the methods
exposed by LinkFactory are inconsistent, for instance. (some of the methods
take String parameters and fetch a node in the repository from that, others
take a node - as a consequence, client code (or LinkFactory itself) gets messy
- on some occasions, it has to use both methods, and exception handling gets
messy, too. The fetching of nodes should be entirely handled by either
LinkFactory itself - or the client code.
One example is at {{createLink(String uuid, String repository, String
fallbackHandle, String nodeDataName, String extension, String anchor, String
parameters)}}
There are other little quirks of the same sort that could use a little
review/cleanup/rename - think testability and separation of concerns.
Additionally, we should remove/review usage of deprecated classes
({{info.magnolia.cms.link.*}}) in our own code!
Some context:
{{info.magnolia.module.fckeditor.dialogs.FckEditorDialog#convertToView}} and
its usage of {{info.magnolia.link.LinkUtil#convertLinksFromUUIDPattern}} - this
is a usecase where you don't want the exceptions to bubble up. The input might
have multiple links, and depending on the use case (editor, rendering, ...) one
might want to render the "broken" links (i.e {{<a href="/fallbackHandle">my
link</a>}}) or just the link description ({{my link}}, no surrounding {{<a>}}),
or let an exception be thrown at the first broken link. (this is not something
the api is currently target for, since {{LinkTransformer}} does not take html
into account, and {{Link}} does not have a notion of it's content/description)
> Further improve/consolidate Link api
> ------------------------------------
>
> Key: MAGNOLIA-2872
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2872
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Reporter: Grégory Joseph
> Assignee: Philipp Bärfuss
> Priority: Minor
> Fix For: 4.2
>
>
> There are some places in the Link api that could be improved; the methods
> exposed by LinkFactory are inconsistent, for instance. (some of the methods
> take String parameters and fetch a node in the repository from that, others
> take a node - as a consequence, client code (or LinkFactory itself) gets
> messy - on some occasions, it has to use both methods, and exception
> handling gets messy, too. The fetching of nodes should be entirely handled by
> either LinkFactory itself - or the client code.
> One example is at {{createLink(String uuid, String repository, String
> fallbackHandle, String nodeDataName, String extension, String anchor, String
> parameters)}}
> There are other little quirks of the same sort that could use a little
> review/cleanup/rename - think testability and separation of concerns.
> Also see MAGNOLIA-2259 - the solution to that issue introduced the usage of
> some jackrabbit API, which we should avoid.
> Additionally, we should remove/review usage of deprecated classes
> ({{info.magnolia.cms.link.*}}) in our own code!
> Some context:
> {{info.magnolia.module.fckeditor.dialogs.FckEditorDialog#convertToView}} and
> its usage of {{info.magnolia.link.LinkUtil#convertLinksFromUUIDPattern}} -
> this is a usecase where you don't want the exceptions to bubble up. The input
> might have multiple links, and depending on the use case (editor, rendering,
> ...) one might want to render the "broken" links (i.e {{<a
> href="/fallbackHandle">my link</a>}}) or just the link description ({{my
> link}}, no surrounding {{<a>}}), or let an exception be thrown at the first
> broken link. (this is not something the api is currently target for, since
> {{LinkTransformer}} does not take html into account, and {{Link}} does not
> have a notion of it's content/description)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
