13 Jan
2011
13 Jan
'11
1:19 a.m.
On 01/12/2011 08:30 AM, Caleb James DeLisle wrote:
On 01/11/2011 11:50 AM, Vincent Massol wrote:
c.x.x.a.Document is deprecated implementation, but not necessarily a
deprecated API. In the future there will be a new Document API,
implemented in a different way, with a different collection of methods,
but the current and the future sets of methods will overlap. It is safe
to add new methods to API objects that are very likely to exist as
components, if the new methods are also likely to be part of the future
API. And I think that getPlainTitle should also exist in the future
Document.
On Jan 11, 2011, at 3:34 PM, Caleb James DeLisle wrote:
IMO The cost of increasing the amount of deprecated API outweighs the cost of hardcoding
strings in
script. I should have said that I think there must be some use case with a compelling
rationale
which is simply impossible without the addition to the API. As it is now, we have
velocity code with
hardcoded strings and thus it must be refactored. With this change we will have velocity
code which
depends on deprecated API (Correct me if c.x.x.api.Document is not deprecated) and thus
must be
refactored.
I will let my -0 stand because it's not something I like the sound of but I accept
that there are
many valid ways of doing things and I may well be missing an important piece if
information.
On 01/10/2011 12:35 PM, Vincent Massol wrote:
yes because we don't want user of the API (from velocity) hardcoding strings as much
as possible. They don't need to know that internally there's a plain text renderer
called "plain/1.0".
Hi devs,
In lots of places we need to display the title without any markup rendering. Examples:
- breadcrumb
- activity stream
- search results
etc
This is such a common use case I'm proposing to add a new API for it in Document:
getPlainTitle()
It's a one liner that will do:
getRenderedTitle("plain/1.0")
You mean adding an alias to c.x.x.api.Document#getRenderedTitle("plain/1.0")?
If so, I am -0 on that because as I understand,
c.x.x.api.Document is on the road to being retired
with the old core and any new APIs there should
have very compelling rationales.
What part is not compelling?
>
>> At least (IMO) they
>> should provide functionality which was previously unavailable without programming
permission.
>
> That's why I haven't proposed to put this in XWiiDocument but only in
Document. Document is scripting API and it makes a lot of sense for scripting, especially
since we don't have a way of sharing a final static String in Velocity.
>
> Thanks
> -Vincent
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/