In Sun's REST architecture style (JSR 311: JAX-RS: The Java API for RESTful
Web Services <https://jsr311.dev.java.net/>), they also use annotations,
like:
@HttpMethod("GET")
@ProduceMime("text/plain")
public String sayHello() {
return new String("Hello there.");
}
(excerpt from
http://weblogs.java.net/blog/bleonard/archive/2007/07/an_introduction_1.html)
In their case, different methods might return different results, depending
on the requested MIME type. If we would annotate components, maybe there
could be different components for different mime types, or a component might
manifest itself differently based on the requested type.
On 9/18/07, Fernando Padilla <[EMAIL PROTECTED]> wrote:
>
> I am one of those working on tapestry and facebook. I don't think it's
> big deal as to the extension, but read on for some possible future ideas.
>
>
>
> Here is an idea out of left field. I wonder if there is anything that
> we can do to have tapestry be more content-type friendly:
>
> 1) break out all components that are html specific to tapestry-html
> library. It's not hard to include tapestry-html in your dependencies, it
> will be cleaner, and get you thinking about what is or is not tied to
> html..
>
> 2) somehow have component loader be aware of the extension or
> content-type of the page/template (.html, .xhtml, .fbml, etc ), and
> maybe use that information to set the content-type of the output, or
> maybe even change how it selects components and mixins. So that we
> might be able to override or change the default behavior for other
> components.. t:pagelink could possibly behave differently for .fbml
> templates than for .html templates.. or some components would only be
> available within the appropriate content-type...
>
>
>
>
> Howard Lewis Ship wrote:
> > I'm on the fence on this; I agree that .xml might be a more appropriate
> > extension, or something Tapestry specific, such as ".tml". Certainly
> we're
> > starting see people want to use Tapestry to create non-HTML, such as SVG
> and
> > something related to Facebook.
> >
> > On the other hand, the easy integration with editors should not be
> > discounted.
> >
> > Let see what others think ... it's not a huge change at this point to
> change
> > the extension.
> >
> > On 9/17/07, Daniel Jue <[EMAIL PROTECTED]> wrote:
> >> Having the templates with an html extension allows easier integration
> >> with you preferred html editor, such as Dreamweaver. ("edit with")
> >> Whereas you may want xml documents opened with Notepad++ (Great, by
> >> the way), etc.
> >>
> >> If anything, they should be .xhtml documents.
> >>
> >> Another problem might be that some browsers may not have their mime
> >> types properly set--about the only mime type you can guarantee to work
> >> is for html. I think xml and xhtml are delivered as something other
> >> than text usually.
> >>
> >> This is pretty old, but check out:
> >> http://www.ookingdom.com/design/xhtml
> >>
> >>
> >>
> >>
> >> On 9/17/07, Christian Gruber <[EMAIL PROTECTED]> wrote:
> >>> It occurs to me that having .html as a file extension on the template
> >>> files is weird, especially since they are by necessity well-formed xml
> >>> documents, which html documents are not. Since they might be other
> >>> kinds of documents than xhtml, would it make more sense to have them
> >>> called .xml documents? It's a small thing, but worth considering.
> >>>
> >>> Christian.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
