You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Lester Chua <ci...@gmail.com> on 2009/12/02 02:17:38 UTC
Re: General questions regarding Wicket roadmap and plans
Hi,
Took some time to pick up this thread again as we were preparing for the
UAT of the application rewrite using Wicket =) for the last 2 weeks.
The UAT was quite successful, with minor modifications required (expected).
The real good news is that Wicket performed admirably in terms of
productivity and the bugs tracing and fixes in the lead up to the UAT.
We rewrote the modules in under a month (the original took about 4). The
productivity boost actually came from the tweaks we needed for UI
interaction as well as code tracing when unexpected behaviour occured.
The experience using Wicket has been real refreshing, I truly enjoyed
the departure from the model2 as well as the json-rest/rich-client
frameworks we were used to.
Ok enough ambling. I have some responses below.
Igor Vaynberg wrote:
> On Wed, Nov 18, 2009 at 9:27 PM, Lester Chua <ci...@gmail.com> wrote:
>
>> Thanks for the reply.
>>
>>
>>>> 1) Product Roadmap (Release plans, upcoming features etc)
>>>> This is important to us because it will at least indicate the intentions
>>>> of
>>>> Wicket Team. As any technology that is adopted enterprise-wide needs to
>>>> be
>>>> long-lived and well supported in addition to it's features and
>>>> technology,
>>>> some visibility about the product lifecycle is required.
>>>>
>>>>
>>> http://cwiki.apache.org/WICKET/wicket-15-wish-list.html
>>> http://cwiki.apache.org/WICKET/wicket-14-wish-list.html
>>>
>>>
>> I did see the wishlist but was wishing for something more like a roadmap
>> with projected release timelines, I can see why that it will probably not be
>> accurate for an open sourced project but an indication of a rough ETA and
>> included features will be good.
>>
>> By the way, is the wishlist official? As in are the features present in the
>> wishlist official? Or is the wishlist used as an idea incubator/exchange?
>>
>
> its an idea incubator
>
Although it's nice to have the wishlist, it's a shame that the Wicket
does not publish a roadmap (even a limited one with just key specific
features to be improved on).
Is is a resource/maintenance issue you have that prevents you from doing
so? Or is it more of a management decision to not publish the roadmap so
that you can avoid "commiting" to a timeline?
The reason why I'm asking this is partly selfish. The organization that
I'm pushing Wicket in has a technical committee that review
frameworks/platforms for use. Anything that does not fall into their
recommended list will need a waiver to be used and deployed. Yea I
know, very cumbersome but it's a fact of life here, and I suspect in
many other organizations that have security as one of their top concerns.
After using Wicket in a real life app conversion, I think I'm able to
address most points that has been raised including security (very
pleased on that front) and productivity etc. But part of the checklist I
am forced to go through is estimated product life span, road map etc.
Unfortunately, It's here that I'm stumped. Has anyone else been through
this hoop-la-loop that your organization forced you to go through for
the introduction of Wicket? If so it'll be great if the information on
how that was achieved can be shared as it'll help me immensely in the
fight to get Wicket into my enterprise environment.
>>> 2) Recent Adoption Statistics (No of downloads, usage projections)
>>> We need this to gauge the interest in the project. Has it peaked? What
>>> is the pattern like?
>>>
>>> ++ Nice idea
>>>
>>>
>>>
>>>> a) Although there is examples and documentation available on Wicket main
>>>> site and Wicket stuff, I find that the organization of the information is
>>>> probably not friendly enough for easy viewing. E.g. the examples site
>>>> does
>>>> not contain source and viewable example together in an easy to read page.
>>>> This can be improved on significantly.
>>>>
>>>>
>>> "you and your team are welcome to contribute, great ideas btw"
>>>
>>>
>>>
>> Planning to once I get up to speed.
>>
>>>> Being such an easy to use component framework, I am really puzzled about
>>>> why the
>>>> plugin development seems so bare
>>>>
>>>>
>>> One reason is that it's so easy to make plugins it feels unnecessary
>>> to publish them.
>>>
>>>
>>>
>> Actually I kinda disagree. Take Delphi which was awesome for it's component
>> architecture and IDE. Writing components and packaging them was very easy
>> but it had a HUGE thriving component library market place where you can
>> literally purchase thousands of packages and libraries.
>>
>
> desktops apps are different, you can build any kind of component you
> want. wicket works with server-side html and there is a limited set of
> things you can build. if you need a slider then the chances are we
> wont provide it, we dont need to, just use wicket to output a hidden
> field and make a slider out of it using jquery or some other frontend
> library. in about two minutes you can wrap that into a jqueryslider
> component, would you take the time to share something that took two
> minutes to build? some people do, there are a couple of projects out
> there that provide integrations between wicket and jquery, but most
> people dont end up sharing.
>
>
In terms of functionalities that users want that can be offered, they
are not that much different. When Desktop apps are common in the
enterprises, most desktop apps are just a front that baby sits a
database. True what you can achieve and how you achieve is very
different on desktops vs web, but what I'm comparing here is that Wicket
should leverage it's component aspect to advance itself as a product.
Technical excellence is rarely a determinant in deciding whether a
product achieves widespread adoption. Marketing, Mindshare, Support, are
very important. Look at the piece of junk JSF has achieved in terms of
adoption. After working a bit more with Wicket, I can see that what you
say is kinda true. But that does not mean that Wicket will not benefit
from a market place for the quick and easy solution. Need a component
that behaves like the once exactly, why just download a 20 bucks JAR and
pluck it into my app and saves 2 hours of coding/testing (I'm not at the
stage that I can build a component in 2 minutes yet =)).
A market place also indicates VERY accurately the adoption rates and
activity for new comers like myself. It is very reassuring to know that
the last component on sale/or distributed as freeware was released just
a couple of weeks ago and there are more that X components actively
maintained.
>>>> c) The mailing list is wonderful and I have had some questions very
>>>> quickly
>>>> answered, which points to an active and supportive community for which
>>>> I'm
>>>> grateful. If there is a way to harness this and make the information more
>>>> easily accessible, it'll be awesome.
>>>>
>>>>
>>> Google reaches most of the discussion via nable/osdir.
>>>
>>>
>>>
>> Yea, that is how I got most of the solutions to my little set of problems.
>> =) Just wishing that it can be better.
>>
>
> hrm, you posted about six messages on our lists, and most times you
> got an answer within a couple of hours. that is better then most
> commercial support out there. and yet you are still complaining? :)
>
> -igor
>
>
And I truly appreciate that =).
>>> My 2cents worth ;)
>>>
>>>
>>> **
>>> Martin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Igor Vaynberg <ig...@gmail.com>.
like this?
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/calendarviews-parent/
-igor
On Thu, Dec 3, 2009 at 8:32 PM, ljw1001 <lj...@gmail.com> wrote:
>
> I agree that more components are needed and would add that a good calendar
> would be a great place to start.
>
> On Dec 3, 2009, at 11:16 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>
>> the interesting bit is that people are saying that there are "not
>> enough components" that wicket ships with, but no one is saying which
>> componets exactly they are missing.
>>
>> -igor
>>
>> On Thu, Dec 3, 2009 at 7:41 PM, Ashley Aitken <mr...@mac.com> wrote:
>>>
>>> On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
>>>
>>>> but as you will see, there is not much
>>>> demand for precanned components out there, they are just too easy to
>>>> roll yourself and there are a lot of open source ones that you can at
>>>> least get ideas from for your specific requirements.
>>>
>>> But isn't that missing some of the major reasons for using components:
>>>
>>> 1. that you shouldn't have to reinvent the wheel (even if it is easy),
>>> 2. that a component that is tried and tested (version 3+) is better than
>>> my
>>> version 1,
>>> 3. components can encapsulate best practice that takes time to learn,
>>> 4. a suite of components may integrate better.
>>>
>>> Writing a linked list in Java is easy but I would never consider doing
>>> that,
>>> the available classe are much more powerful, general, well-tested,
>>> integrated, ...
>>>
>>> I'm not knowledgeable wrt Wicket components or JSF components, but
>>> generally
>>> speaking what components available in JSF, for example, wouldn't be
>>> useful
>>> in Wicket and why not?
>>>
>>> I'm with the OP in that I'm a little surprised by the lack of published
>>> components (from low-level to high-level). Again, I am probably missing
>>> something ...
>>>
>>> Maybe as I learn more about Wicket and get more experience I will
>>> understand.
>>>
>>> Cheers,
>>> Ashley.
>>>
>>> --
>>> Ashley Aitken
>>> Perth, Western Australia
>>> Skype/iChat: MrHatken (GMT + 8hrs!)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by ljw1001 <lj...@gmail.com>.
I agree that more components are needed and would add that a good
calendar would be a great place to start.
On Dec 3, 2009, at 11:16 PM, Igor Vaynberg <ig...@gmail.com>
wrote:
> the interesting bit is that people are saying that there are "not
> enough components" that wicket ships with, but no one is saying which
> componets exactly they are missing.
>
> -igor
>
> On Thu, Dec 3, 2009 at 7:41 PM, Ashley Aitken <mr...@mac.com>
> wrote:
>>
>> On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
>>
>>> but as you will see, there is not much
>>> demand for precanned components out there, they are just too easy to
>>> roll yourself and there are a lot of open source ones that you can
>>> at
>>> least get ideas from for your specific requirements.
>>
>> But isn't that missing some of the major reasons for using
>> components:
>>
>> 1. that you shouldn't have to reinvent the wheel (even if it is
>> easy),
>> 2. that a component that is tried and tested (version 3+) is better
>> than my
>> version 1,
>> 3. components can encapsulate best practice that takes time to learn,
>> 4. a suite of components may integrate better.
>>
>> Writing a linked list in Java is easy but I would never consider
>> doing that,
>> the available classe are much more powerful, general, well-tested,
>> integrated, ...
>>
>> I'm not knowledgeable wrt Wicket components or JSF components, but
>> generally
>> speaking what components available in JSF, for example, wouldn't be
>> useful
>> in Wicket and why not?
>>
>> I'm with the OP in that I'm a little surprised by the lack of
>> published
>> components (from low-level to high-level). Again, I am probably
>> missing
>> something ...
>>
>> Maybe as I learn more about Wicket and get more experience I will
>> understand.
>>
>> Cheers,
>> Ashley.
>>
>> --
>> Ashley Aitken
>> Perth, Western Australia
>> Skype/iChat: MrHatken (GMT + 8hrs!)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Lester Chua <ci...@gmail.com>.
But you did release them and obtained a financial benefit from the
releases, the very fact that it is released to the outside world make
others know of your existance and improves your exposure tremendously.
The particular point under discussion originally was whether a good and
active component marketplace/showcase site for Wicket will help drive
the adoption and acceptance rate, as well as allow newbies like myself
to pick up and use Wicket more easily. It's not about the difficulty or
ease of creating/maintaining components in Wicket.
Well, it's been pointed out that it's more of a resource issue to
maintain such a site and I guess we'll just have to leave it at that,
until someone outside the core Wicket team takes up the gauntlet and
build one for the rest of us. =)
Lester
Jeremy Thomerson wrote:
> +1000 to Martijn's comment. I've released a few open source components -
> and none are at the level to be sold. Not because they can't be used - I do
> use them in production. But because there are a million use cases and I
> have no desire, time, or monetary reason to accommodate those use cases.
> Instead, if people contact me, I will either build them a custom component
> for hire or will allow them to pay me to add features to an open source
> one.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Fri, Dec 4, 2009 at 2:54 AM, Martijn Dashorst <martijn.dashorst@gmail.com
>
>> wrote:
>>
>
>
>> The problem with pre built components is that they never, ever are
>> exactly what you want or need. Maintaining such components for other
>> people is what I call hell. We are in the business of creating the
>> best Java web framework for building your own custom components with
>> unprecedented ease. This takes enough time already.
>>
>> Anybody is welcome to build component libraries, open source or
>> commercially. Our license allows for that and nobody would object to
>> creative folks trying to earn a buck or two with their component
>> (libraries).
>>
>> That this hasn't happened (yet) is mostly because it is so damned easy
>> to create your own custom components according to your coding style
>> that precisely fit in your application and perform exactly those task
>> you intend them to. And conversely it is damned hard to create a
>> finished, polished, released component. It is easy to start a
>> component, but it is *work* to ship it.
>>
>> Martijn
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Jeremy Thomerson <je...@wickettraining.com>.
+1000 to Martijn's comment. I've released a few open source components -
and none are at the level to be sold. Not because they can't be used - I do
use them in production. But because there are a million use cases and I
have no desire, time, or monetary reason to accommodate those use cases.
Instead, if people contact me, I will either build them a custom component
for hire or will allow them to pay me to add features to an open source
one.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, Dec 4, 2009 at 2:54 AM, Martijn Dashorst <martijn.dashorst@gmail.com
> wrote:
> The problem with pre built components is that they never, ever are
> exactly what you want or need. Maintaining such components for other
> people is what I call hell. We are in the business of creating the
> best Java web framework for building your own custom components with
> unprecedented ease. This takes enough time already.
>
> Anybody is welcome to build component libraries, open source or
> commercially. Our license allows for that and nobody would object to
> creative folks trying to earn a buck or two with their component
> (libraries).
>
> That this hasn't happened (yet) is mostly because it is so damned easy
> to create your own custom components according to your coding style
> that precisely fit in your application and perform exactly those task
> you intend them to. And conversely it is damned hard to create a
> finished, polished, released component. It is easy to start a
> component, but it is *work* to ship it.
>
> Martijn
>
Re: General questions regarding Wicket roadmap and plans
Posted by Martijn Dashorst <ma...@gmail.com>.
The problem with pre built components is that they never, ever are
exactly what you want or need. Maintaining such components for other
people is what I call hell. We are in the business of creating the
best Java web framework for building your own custom components with
unprecedented ease. This takes enough time already.
Anybody is welcome to build component libraries, open source or
commercially. Our license allows for that and nobody would object to
creative folks trying to earn a buck or two with their component
(libraries).
That this hasn't happened (yet) is mostly because it is so damned easy
to create your own custom components according to your coding style
that precisely fit in your application and perform exactly those task
you intend them to. And conversely it is damned hard to create a
finished, polished, released component. It is easy to start a
component, but it is *work* to ship it.
Martijn
On Fri, Dec 4, 2009 at 6:37 AM, Lester Chua <ci...@gmail.com> wrote:
> I think it's kinda of chicken and egg issue wrt components.
> If newbies do not see components readily available, they will probably end
> up coding what they want themselves because:
>
> 1) it takes time to articulate properly their requirements
> 2) avoid facing potential embarrassment because the component that they
> want is "trivial" (which turns out not to be)
> 3) "I know it when I see it" (this is quite common and this approach
> normally requires a large library of things to pick from)
>
> Maybe the reason why no one is asking is one of the above reasons, or all of
> them combined.
>
>
> Igor Vaynberg wrote:
>>
>> the interesting bit is that people are saying that there are "not
>> enough components" that wicket ships with, but no one is saying which
>> componets exactly they are missing.
>>
>> -igor
>>
>> On Thu, Dec 3, 2009 at 7:41 PM, Ashley Aitken <mr...@mac.com> wrote:
>>
>>>
>>> On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
>>>
>>>
>>>>
>>>> but as you will see, there is not much
>>>> demand for precanned components out there, they are just too easy to
>>>> roll yourself and there are a lot of open source ones that you can at
>>>> least get ideas from for your specific requirements.
>>>>
>>>
>>> But isn't that missing some of the major reasons for using components:
>>>
>>> 1. that you shouldn't have to reinvent the wheel (even if it is easy),
>>> 2. that a component that is tried and tested (version 3+) is better than
>>> my
>>> version 1,
>>> 3. components can encapsulate best practice that takes time to learn,
>>> 4. a suite of components may integrate better.
>>>
>>> Writing a linked list in Java is easy but I would never consider doing
>>> that,
>>> the available classe are much more powerful, general, well-tested,
>>> integrated, ...
>>>
>>> I'm not knowledgeable wrt Wicket components or JSF components, but
>>> generally
>>> speaking what components available in JSF, for example, wouldn't be
>>> useful
>>> in Wicket and why not?
>>>
>>> I'm with the OP in that I'm a little surprised by the lack of published
>>> components (from low-level to high-level). Again, I am probably missing
>>> something ...
>>>
>>> Maybe as I learn more about Wicket and get more experience I will
>>> understand.
>>>
>>> Cheers,
>>> Ashley.
>>>
>>> --
>>> Ashley Aitken
>>> Perth, Western Australia
>>> Skype/iChat: MrHatken (GMT + 8hrs!)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Lester Chua <ci...@gmail.com>.
I think it's kinda of chicken and egg issue wrt components.
If newbies do not see components readily available, they will probably
end up coding what they want themselves because:
1) it takes time to articulate properly their requirements
2) avoid facing potential embarrassment because the component that they
want is "trivial" (which turns out not to be)
3) "I know it when I see it" (this is quite common and this approach
normally requires a large library of things to pick from)
Maybe the reason why no one is asking is one of the above reasons, or
all of them combined.
Igor Vaynberg wrote:
> the interesting bit is that people are saying that there are "not
> enough components" that wicket ships with, but no one is saying which
> componets exactly they are missing.
>
> -igor
>
> On Thu, Dec 3, 2009 at 7:41 PM, Ashley Aitken <mr...@mac.com> wrote:
>
>> On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
>>
>>
>>> but as you will see, there is not much
>>> demand for precanned components out there, they are just too easy to
>>> roll yourself and there are a lot of open source ones that you can at
>>> least get ideas from for your specific requirements.
>>>
>> But isn't that missing some of the major reasons for using components:
>>
>> 1. that you shouldn't have to reinvent the wheel (even if it is easy),
>> 2. that a component that is tried and tested (version 3+) is better than my
>> version 1,
>> 3. components can encapsulate best practice that takes time to learn,
>> 4. a suite of components may integrate better.
>>
>> Writing a linked list in Java is easy but I would never consider doing that,
>> the available classe are much more powerful, general, well-tested,
>> integrated, ...
>>
>> I'm not knowledgeable wrt Wicket components or JSF components, but generally
>> speaking what components available in JSF, for example, wouldn't be useful
>> in Wicket and why not?
>>
>> I'm with the OP in that I'm a little surprised by the lack of published
>> components (from low-level to high-level). Again, I am probably missing
>> something ...
>>
>> Maybe as I learn more about Wicket and get more experience I will
>> understand.
>>
>> Cheers,
>> Ashley.
>>
>> --
>> Ashley Aitken
>> Perth, Western Australia
>> Skype/iChat: MrHatken (GMT + 8hrs!)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Igor Vaynberg <ig...@gmail.com>.
the interesting bit is that people are saying that there are "not
enough components" that wicket ships with, but no one is saying which
componets exactly they are missing.
-igor
On Thu, Dec 3, 2009 at 7:41 PM, Ashley Aitken <mr...@mac.com> wrote:
>
> On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
>
>> but as you will see, there is not much
>> demand for precanned components out there, they are just too easy to
>> roll yourself and there are a lot of open source ones that you can at
>> least get ideas from for your specific requirements.
>
> But isn't that missing some of the major reasons for using components:
>
> 1. that you shouldn't have to reinvent the wheel (even if it is easy),
> 2. that a component that is tried and tested (version 3+) is better than my
> version 1,
> 3. components can encapsulate best practice that takes time to learn,
> 4. a suite of components may integrate better.
>
> Writing a linked list in Java is easy but I would never consider doing that,
> the available classe are much more powerful, general, well-tested,
> integrated, ...
>
> I'm not knowledgeable wrt Wicket components or JSF components, but generally
> speaking what components available in JSF, for example, wouldn't be useful
> in Wicket and why not?
>
> I'm with the OP in that I'm a little surprised by the lack of published
> components (from low-level to high-level). Again, I am probably missing
> something ...
>
> Maybe as I learn more about Wicket and get more experience I will
> understand.
>
> Cheers,
> Ashley.
>
> --
> Ashley Aitken
> Perth, Western Australia
> Skype/iChat: MrHatken (GMT + 8hrs!)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Ashley Aitken <mr...@mac.com>.
On 02/12/2009, at 10:45 AM, Igor Vaynberg wrote:
> but as you will see, there is not much
> demand for precanned components out there, they are just too easy to
> roll yourself and there are a lot of open source ones that you can at
> least get ideas from for your specific requirements.
But isn't that missing some of the major reasons for using components:
1. that you shouldn't have to reinvent the wheel (even if it is easy),
2. that a component that is tried and tested (version 3+) is better
than my version 1,
3. components can encapsulate best practice that takes time to learn,
4. a suite of components may integrate better.
Writing a linked list in Java is easy but I would never consider doing
that, the available classe are much more powerful, general, well-
tested, integrated, ...
I'm not knowledgeable wrt Wicket components or JSF components, but
generally speaking what components available in JSF, for example,
wouldn't be useful in Wicket and why not?
I'm with the OP in that I'm a little surprised by the lack of
published components (from low-level to high-level). Again, I am
probably missing something ...
Maybe as I learn more about Wicket and get more experience I will
understand.
Cheers,
Ashley.
--
Ashley Aitken
Perth, Western Australia
Skype/iChat: MrHatken (GMT + 8hrs!)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Dec 1, 2009 at 5:17 PM, Lester Chua <ci...@gmail.com> wrote:
> Hi,
>
> Took some time to pick up this thread again as we were preparing for the UAT
> of the application rewrite using Wicket =) for the last 2 weeks.
> The UAT was quite successful, with minor modifications required (expected).
> The real good news is that Wicket performed admirably in terms of
> productivity and the bugs tracing and fixes in the lead up to the UAT.
> We rewrote the modules in under a month (the original took about 4). The
> productivity boost actually came from the tweaks we needed for UI
> interaction as well as code tracing when unexpected behaviour occured.
>
> The experience using Wicket has been real refreshing, I truly enjoyed the
> departure from the model2 as well as the json-rest/rich-client frameworks
> we were used to.
>
> Ok enough ambling. I have some responses below.
>
> Igor Vaynberg wrote:
>>
>> On Wed, Nov 18, 2009 at 9:27 PM, Lester Chua <ci...@gmail.com> wrote:
>>
>>>
>>> Thanks for the reply.
>>>
>>>
>>>>>
>>>>> 1) Product Roadmap (Release plans, upcoming features etc)
>>>>> This is important to us because it will at least indicate the
>>>>> intentions
>>>>> of
>>>>> Wicket Team. As any technology that is adopted enterprise-wide needs to
>>>>> be
>>>>> long-lived and well supported in addition to it's features and
>>>>> technology,
>>>>> some visibility about the product lifecycle is required.
>>>>>
>>>>>
>>>>
>>>> http://cwiki.apache.org/WICKET/wicket-15-wish-list.html
>>>> http://cwiki.apache.org/WICKET/wicket-14-wish-list.html
>>>>
>>>>
>>>
>>> I did see the wishlist but was wishing for something more like a roadmap
>>> with projected release timelines, I can see why that it will probably not
>>> be
>>> accurate for an open sourced project but an indication of a rough ETA and
>>> included features will be good.
>>>
>>> By the way, is the wishlist official? As in are the features present in
>>> the
>>> wishlist official? Or is the wishlist used as an idea incubator/exchange?
>>>
>>
>> its an idea incubator
>>
>
> Although it's nice to have the wishlist, it's a shame that the Wicket does
> not publish a roadmap (even a limited one with just key specific features to
> be improved on).
> Is is a resource/maintenance issue you have that prevents you from doing so?
> Or is it more of a management decision to not publish the roadmap so that
> you can avoid "commiting" to a timeline?
>
> The reason why I'm asking this is partly selfish. The organization that I'm
> pushing Wicket in has a technical committee that review frameworks/platforms
> for use. Anything that does not fall into their recommended list will need a
> waiver to be used and deployed. Yea I know, very cumbersome but it's a fact
> of life here, and I suspect in many other organizations that have security
> as one of their top concerns.
>
> After using Wicket in a real life app conversion, I think I'm able to
> address most points that has been raised including security (very pleased on
> that front) and productivity etc. But part of the checklist I am forced to
> go through is estimated product life span, road map etc.
>
> Unfortunately, It's here that I'm stumped. Has anyone else been through this
> hoop-la-loop that your organization forced you to go through for the
> introduction of Wicket? If so it'll be great if the information on how that
> was achieved can be shared as it'll help me immensely in the fight to get
> Wicket into my enterprise environment.
it is a combination of all these things. mainly we do not want to
commit to a feature set because we do not know what our resources will
be during the build phase. we have a general idea of what we want to
do and how, and that is outlined in discussions on the mailing lists.
>>>> 2) Recent Adoption Statistics (No of downloads, usage projections)
>>>> We need this to gauge the interest in the project. Has it peaked? What
>>>> is the pattern like?
>>>>
>>>> ++ Nice idea
>>>>
>>>>
>>>>
>>>>>
>>>>> a) Although there is examples and documentation available on Wicket
>>>>> main
>>>>> site and Wicket stuff, I find that the organization of the information
>>>>> is
>>>>> probably not friendly enough for easy viewing. E.g. the examples site
>>>>> does
>>>>> not contain source and viewable example together in an easy to read
>>>>> page.
>>>>> This can be improved on significantly.
>>>>>
>>>>>
>>>>
>>>> "you and your team are welcome to contribute, great ideas btw"
>>>>
>>>>
>>>>
>>>
>>> Planning to once I get up to speed.
>>>
>>>>>
>>>>> Being such an easy to use component framework, I am really puzzled
>>>>> about
>>>>> why the
>>>>> plugin development seems so bare
>>>>>
>>>>>
>>>>
>>>> One reason is that it's so easy to make plugins it feels unnecessary
>>>> to publish them.
>>>>
>>>>
>>>>
>>>
>>> Actually I kinda disagree. Take Delphi which was awesome for it's
>>> component
>>> architecture and IDE. Writing components and packaging them was very easy
>>> but it had a HUGE thriving component library market place where you can
>>> literally purchase thousands of packages and libraries.
>>>
>>
>> desktops apps are different, you can build any kind of component you
>> want. wicket works with server-side html and there is a limited set of
>> things you can build. if you need a slider then the chances are we
>> wont provide it, we dont need to, just use wicket to output a hidden
>> field and make a slider out of it using jquery or some other frontend
>> library. in about two minutes you can wrap that into a jqueryslider
>> component, would you take the time to share something that took two
>> minutes to build? some people do, there are a couple of projects out
>> there that provide integrations between wicket and jquery, but most
>> people dont end up sharing.
>>
>>
>
> In terms of functionalities that users want that can be offered, they are
> not that much different. When Desktop apps are common in the enterprises,
> most desktop apps are just a front that baby sits a database. True what you
> can achieve and how you achieve is very different on desktops vs web, but
> what I'm comparing here is that Wicket should leverage it's component aspect
> to advance itself as a product.
>
> Technical excellence is rarely a determinant in deciding whether a product
> achieves widespread adoption. Marketing, Mindshare, Support, are very
> important. Look at the piece of junk JSF has achieved in terms of adoption.
> After working a bit more with Wicket, I can see that what you say is kinda
> true. But that does not mean that Wicket will not benefit from a market
> place for the quick and easy solution. Need a component that behaves like
> the once exactly, why just download a 20 bucks JAR and pluck it into my app
> and saves 2 hours of coding/testing (I'm not at the stage that I can build a
> component in 2 minutes yet =)).
>
> A market place also indicates VERY accurately the adoption rates and
> activity for new comers like myself. It is very reassuring to know that the
> last component on sale/or distributed as freeware was released just a couple
> of weeks ago and there are more that X components actively maintained.
you are welcome to build one. but as you will see, there is not much
demand for precanned components out there, they are just too easy to
roll yourself and there are a lot of open source ones that you can at
least get ideas from for your specific requirements.
-igor
>
>
>>>>> c) The mailing list is wonderful and I have had some questions very
>>>>> quickly
>>>>> answered, which points to an active and supportive community for which
>>>>> I'm
>>>>> grateful. If there is a way to harness this and make the information
>>>>> more
>>>>> easily accessible, it'll be awesome.
>>>>>
>>>>>
>>>>
>>>> Google reaches most of the discussion via nable/osdir.
>>>>
>>>>
>>>>
>>>
>>> Yea, that is how I got most of the solutions to my little set of
>>> problems.
>>> =) Just wishing that it can be better.
>>>
>>
>> hrm, you posted about six messages on our lists, and most times you
>> got an answer within a couple of hours. that is better then most
>> commercial support out there. and yet you are still complaining? :)
>>
>> -igor
>>
>>
>
> And I truly appreciate that =).
>
>>>> My 2cents worth ;)
>>>>
>>>>
>>>> **
>>>> Martin
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org