You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Greg Reddin <li...@reddin.org> on 2005/10/06 17:27:19 UTC
[Standalone Tiles] Tiles Refactoring Part 2
I hope no one who has worked on Tiles in the past - especially Cedric
- takes offense to this because none is intended. But here goes...
Every time I dig into Tiles I'm overwhelmed by the complexity of the
API. IMHO, it seems like Tiles employs way too many classes to do
it's job. I wanted to do the work required to extract the Servlet
API dependencies, but I'm finding my brain is not able to think about
all the pieces at one time. So, my proposal is to further refine the
API to simplify it as much as possible. Ideally, I'd like to pare
the internal API back to just the bare essentials. I'd like
developers who are new to Tiles to be able to follow the code path
easily to solve problems and figure out what's going on. Just like
the last refactoring I did, this work will not change the way users
configure or use Tiles from a JSP perspective at all. I hope the end
result will be a simplified Tiles that makes a lot more sense when
you dive into the code. So here's some questions for the list:
1. Is this worthwhile? If it ain't broke should I avoid fixing it?
On one hand it's worth it to me simply because enhancements to Tiles
are not easy right now. OTOH, I don't know how many enhancements
Tiles really needs. It pretty much does what it needs to do and it
seems like most enhancements are related to porting it to other
architectures.
2. Will this step on someone's toes? I really don't want to divide
the community by doing this. This is not a case of "your code sucks
so I'm going to fix it", but just a case of me wanting to simplify
things so it's easier to keep up with. I'd be happy to work with
anyone who was involved in creating Tiles initially to understand why
the complexity is necessary or whatever. Honestly, I haven't seen a
post from Cedric in quite a while so I wonder if he's moved on to
other things. I fully expect to be flogged if I do something stupid :-)
3. Please be patient. It's taking me a while to walk through the
code paths and figure out what can be factored out or simplified. If
anyone else wants to help, feel free to email me and maybe we can
figure out a collaboration method if the dev list doesn't work. I
have no idea how long this will take so I hope there's not a huge
demand for the integration of standalone Tiles (or that there's other
willing hands).
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Standalone Tiles] Tiles Refactoring Part 2
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Cedric Dumoulin" <ce...@lifl.fr>
> Also, it should be possible to remove all the "alternative names" like
> component, tiles, ... and use the more up to date. This will also simplify
> the documentation and the learning of tiles by new users.
I brought the tld up to JSP 1.2 -- after someone decides what attributes are
staying, I'll add the HTML documentation (copied from Struts Tiles) so it
will show up on the website.
I updated the Standalone Tiles pages on the test site:
http://svn.apache.org/builds/struts/maven/trunk/site-test/struts-sandbox/tiles-core/index.html
The Taglib Reference or Taglibdoc (under Project Reports) pages might be
useful for sorting out the attributes.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Standalone Tiles] Tiles Refactoring Part 2
Posted by Greg Reddin <li...@reddin.org>.
On Oct 6, 2005, at 3:20 PM, Cedric Dumoulin wrote:
> But be care, there is some not so often used API that are used by
> some companies. I hope these APIs will remain. I think of :
> - the possibility to provide another implementation for tiles
> factory (use of a DB ...)
> - the i18n mechanism to load alternative definition files
> - ... (I need to dig into the code to remember :-) )
Yes, I consider these core features and will not remove them.
However some of the APIs have changed a bit. For example
DefinitionsFactory was both a "factory" and a "container". I split
those two concerns into separate components, DefinitionsFactory and
ComponentDefinitions, respectively.
> I keep an eye on the struts dev list, and I try to follow all
> threads about Tiles. So, feel free to ask me more specific
> questions if you need, either on the list or directly.
Very good. I'm glad you're still around. I may need your expertise
along the way :-)
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Standalone Tiles] Tiles Refactoring Part 2
Posted by Cedric Dumoulin <ce...@lifl.fr>.
The Tiles implementation has become complex because of the numerous
backward compatibilities. I think that it is possible to simplify the
code by removing some of them. For example it should be possible to
simplify the way tiles initialize by removing struts 1.0 compatibility
(if it still there). Also, it should be possible to remove all the
"alternative names" like component, tiles, ... and use the more up to
date. This will also simplify the documentation and the learning of
tiles by new users.
But be care, there is some not so often used API that are used by some
companies. I hope these APIs will remain. I think of :
- the possibility to provide another implementation for tiles factory
(use of a DB ...)
- the i18n mechanism to load alternative definition files
- ... (I need to dig into the code to remember :-) )
I keep an eye on the struts dev list, and I try to follow all threads
about Tiles. So, feel free to ask me more specific questions if you
need, either on the list or directly.
Cedric
Greg Reddin wrote:
> I hope no one who has worked on Tiles in the past - especially Cedric
> - takes offense to this because none is intended. But here goes...
>
> Every time I dig into Tiles I'm overwhelmed by the complexity of the
> API. IMHO, it seems like Tiles employs way too many classes to do
> it's job. I wanted to do the work required to extract the Servlet
> API dependencies, but I'm finding my brain is not able to think about
> all the pieces at one time. So, my proposal is to further refine the
> API to simplify it as much as possible. Ideally, I'd like to pare
> the internal API back to just the bare essentials. I'd like
> developers who are new to Tiles to be able to follow the code path
> easily to solve problems and figure out what's going on. Just like
> the last refactoring I did, this work will not change the way users
> configure or use Tiles from a JSP perspective at all. I hope the end
> result will be a simplified Tiles that makes a lot more sense when
> you dive into the code. So here's some questions for the list:
>
> 1. Is this worthwhile? If it ain't broke should I avoid fixing it?
> On one hand it's worth it to me simply because enhancements to Tiles
> are not easy right now. OTOH, I don't know how many enhancements
> Tiles really needs. It pretty much does what it needs to do and it
> seems like most enhancements are related to porting it to other
> architectures.
>
> 2. Will this step on someone's toes? I really don't want to divide
> the community by doing this. This is not a case of "your code sucks
> so I'm going to fix it", but just a case of me wanting to simplify
> things so it's easier to keep up with. I'd be happy to work with
> anyone who was involved in creating Tiles initially to understand why
> the complexity is necessary or whatever. Honestly, I haven't seen a
> post from Cedric in quite a while so I wonder if he's moved on to
> other things. I fully expect to be flogged if I do something stupid :-)
>
> 3. Please be patient. It's taking me a while to walk through the
> code paths and figure out what can be factored out or simplified. If
> anyone else wants to help, feel free to email me and maybe we can
> figure out a collaboration method if the dev list doesn't work. I
> have no idea how long this will take so I hope there's not a huge
> demand for the integration of standalone Tiles (or that there's other
> willing hands).
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Standalone Tiles] Tiles Refactoring Part 2
Posted by Joe Germuska <Jo...@Germuska.com>.
Greg:
A big +1 from me for simplifying Tiles; my hunch is that there are
very few people who have actually written code that depends on the
implementation details of Tiles besides writing Controllers, and I
have frequently shared your sense of puzzlement. Tiles also suffers
from merging from a few code bases and preserving alternative ways of
doing things for longer than is probably necessary.
I encourage you to do what you can to make things easier to follow,
especially seeing as the new package namespace means that everyone
will be aware that a transition has occurred. I think maintaining
backwards compatibility is commendable, but I think there may be
places where you could justify breakage -- at least I'd suggest
remaining open to the possibility.
Joe
At 10:27 AM -0500 10/6/05, Greg Reddin wrote:
>I hope no one who has worked on Tiles in the past - especially
>Cedric - takes offense to this because none is intended. But here
>goes...
>
>Every time I dig into Tiles I'm overwhelmed by the complexity of the
>API. IMHO, it seems like Tiles employs way too many classes to do
>it's job. I wanted to do the work required to extract the Servlet
>API dependencies, but I'm finding my brain is not able to think
>about all the pieces at one time. So, my proposal is to further
>refine the API to simplify it as much as possible. Ideally, I'd
>like to pare the internal API back to just the bare essentials. I'd
>like developers who are new to Tiles to be able to follow the code
>path easily to solve problems and figure out what's going on. Just
>like the last refactoring I did, this work will not change the way
>users configure or use Tiles from a JSP perspective at all. I hope
>the end result will be a simplified Tiles that makes a lot more
>sense when you dive into the code. So here's some questions for the
>list:
>
>1. Is this worthwhile? If it ain't broke should I avoid fixing it?
>On one hand it's worth it to me simply because enhancements to Tiles
>are not easy right now. OTOH, I don't know how many enhancements
>Tiles really needs. It pretty much does what it needs to do and it
>seems like most enhancements are related to porting it to other
>architectures.
>
>2. Will this step on someone's toes? I really don't want to divide
>the community by doing this. This is not a case of "your code sucks
>so I'm going to fix it", but just a case of me wanting to simplify
>things so it's easier to keep up with. I'd be happy to work with
>anyone who was involved in creating Tiles initially to understand
>why the complexity is necessary or whatever. Honestly, I haven't
>seen a post from Cedric in quite a while so I wonder if he's moved
>on to other things. I fully expect to be flogged if I do something
>stupid :-)
>
>3. Please be patient. It's taking me a while to walk through the
>code paths and figure out what can be factored out or simplified.
>If anyone else wants to help, feel free to email me and maybe we can
>figure out a collaboration method if the dev list doesn't work. I
>have no idea how long this will take so I hope there's not a huge
>demand for the integration of standalone Tiles (or that there's
>other willing hands).
>
>Greg
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org