Wow.. Cool.. Thanks! Another one that I had trouble with was Model<List<MyPojo>> I'm guessing cuz the compiler/ide doesn't see List as Serializable.
D/ On 8/20/09 5:57 PM, "Matej Knopp" <matej.kn...@gmail.com> wrote: If your component does not use model you can use <Void>. -Matej On Fri, Aug 21, 2009 at 12:54 AM, Douglas Ferguson<doug...@douglasferguson.us> wrote: > No.. I just finally set our pom to 1.4 and dealing with the 4,000 warnings! > I'm wondering what other folks are doing for thinks like Link(s) or simple > components that don't make use of a model. > In some cases I've just added <String> to make eclipse stop complaining... > > I'll look into @RequireHttps, but now that I have it working, I'm not sure > I'll touch it. > Are there good docs on it anywhere? > > > > D/ > > > On 8/20/09 4:53 PM, "Igor Vaynberg" <igor.vaynb...@gmail.com> wrote: > > have you seen @RequireHttps in 1.4? it is a pita, but its doable. > > -igor > > On Thu, Aug 20, 2009 at 1:53 PM, Douglas > Ferguson<doug...@douglasferguson.us> wrote: >> I agree that this area could benefit from a redesign. >> >> I specifically found it difficult when writing a RequestHandler that would >> redirect request from ssl to non-ssl depending no the page type. >> >> I.E. Login is redirected to HTTPS, then regular page redirects you back to >> HTTP >> >> >> D/ >> >> >> On 8/20/09 3:46 PM, "Igor Vaynberg" <igor.vaynb...@gmail.com> wrote: >> >> the intention is to drastically simply the process of going from a url >> to a page. >> >> right now we have the filter->requestcycle->processor->coding >> strategy->target->page. everything between the filter and the page is >> very complicated. we would like to clean it up and simplify it. >> >> our url handling is a mess. it is spread all over the aforementioned >> objects - encoding, decoding, parameter resolving, relative path >> calculations, context path calculations, etc, etc. we would like to >> create a value object to represent the url, and centralize all that >> logic inside. >> >> we also intend to make it simpler to create custom coding strategies, >> as well as mount non-page-related handlers onto urls. >> >> further, a stretch goal would be to unify the handling of resources >> with this scheme. currently resources are handled via SharedResources >> and are completely separate from the normal process. its more stuff to >> learn and to understand for users, hopefully we can rebuild resources >> to work via the same process as everything else - thus the >> non-page-related handlers mentioned above. >> >> these are all rough ideas, we havent really talked much about them but >> prototyped some code to see what this can potentially look like. >> >> -igor >> >> On Thu, Aug 20, 2009 at 1:33 PM, Martijn >> Dashorst<martijn.dasho...@gmail.com> wrote: >>> It would be nice to get some guidance towards the goals, and >>> architecture of your new design before we commit to it. Just looking >>> at the code doesn't reveal intention or the bigger picture. >>> >>> Martijn >>> >>> On Thu, Aug 20, 2009 at 8:09 PM, Matej Knopp<matej.kn...@gmail.com> wrote: >>>> Hi, >>>> >>>> actually the changes in 1.5 might be quite drastic as far as wicket >>>> internals are concerned. I've already rewritten the request cycle, url >>>> processing and page management. I'm not sure how much of it will >>>> actually get to trunk though. You can take a look at the code here if >>>> you are interested: >>>> >>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng/ >>>> >>>> Note that this is pretty much a prototype. While the request cycle, >>>> url processing and page management work, the rest of wicket is more or >>>> less mocked. >>>> >>>> Also right now it only covers regular request processing. I don't know >>>> enough about portlets to build in portlet support. I'm not even sure >>>> the architecture is flexible enough to allow seamless portlet >>>> integration. That said, it would be much probably lot easier and >>>> cleaner to refactor this code than to add add portlets to existing >>>> wicket trunk - which always feel like a hack to me. >>>> >>>> -Matej >>>> >>>> >>>> >>>> On Thu, Aug 20, 2009 at 8:03 PM, Antony Stubbs<antony.stu...@gmail.com> >>>> wrote: >>>>> There us already a working patch since early this year. I just need to >>>>> update it to trunk which shouldn't be a big deal. >>>>> >>>>> Regards, >>>>> Antony Stubbs >>>>> >>>>> website: sharca.com >>>>> >>>>> On 20/08/2009, at 7:58 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: >>>>> >>>>>> come up with a proposal we can discuss. when we hash out the idea then >>>>>> come up with a patch. >>>>>> >>>>>> proposal==patch is fine as far as you dont mind refactoring as we >>>>>> iterate. >>>>>> >>>>>> -igor >>>>>> >>>>>> On Thu, Aug 20, 2009 at 9:51 AM, Antony Stubbs<antony.stu...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Apologies if this is known, but is there anywhere noted the plan for >>>>>>> 1.5? >>>>>>> >>>>>>> Also, I'd like to look back at the portal events work I did, and try and >>>>>>> get >>>>>>> that into 1.5. What would be the process for doing so? In terms of >>>>>>> making >>>>>>> a >>>>>>> branch, or just re-patching, or do I just need to get the final OK from >>>>>>> Ate? >>>>>>> >>>>>>> Cheers, >>>>>>> Antony Stubbs, >>>>>>> >>>>>>> sharca.com >>>>>>> >>>>>>> On 20/08/2009, at 5:10 PM, Igor Vaynberg wrote: >>>>>>> >>>>>>>> Wicket 1.4.x has been branched and now lives in >>>>>>>> https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x >>>>>>>> Trunk is now what will become 1.5.0. >>>>>>>> >>>>>>>> Trunk may be broken in the early days of development and contain a lot >>>>>>>> of API breaks, so if you are following bleeding edge you may want to >>>>>>>> do so on the 1.4.x branch for a while. >>>>>>>> >>>>>>>> -igor >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>>> For additional commands, e-mail: users-h...@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 >>> >> >> > >
