Re: Scala-Wicket Help and Advice
Either way, you have to put logic somewhere that tries to figure out
what the heck you want to borrow and then figure out where the heck to
get it.
If it is done at compile time you don't need messaging logic. It
would be uniquely defined what you can get.
Please explain.
Think about object hierarchy. It is uniquely defined what method
overrides what etc.
So it would just expand the same idea to membership dimensions in
addition to inheritance dimensions.
I mean that assuming man has a bag would work effectively similar to
man extends bag at compile time.
If bag has a getter then man can expose that getter. However, if we
would really extend bag then we are stuck with it (and we could'nt
have man wear both jacket, trousers and bag at same time).
When man only has bag then we can also change the bag and extend the
bag with another bag or set it to null even.
Nevertheless, we could annotate:
@DefaultExpose(ExposeLevels.ALL)
public class Man {
private Bag bag;
}
public class Customs {
public boolean investigate(Man man) {
Pencil = man.getPencil();
}
}
Alternatively you can move the annotation
public class Man {
@DefaultExpose(ExposeLevels.ALL)
private Bag bag;
}
::: or even more detailed:
public class Bag {
@DefaultExpose(ExposeLevels.ALL)
private PencilCase pencilCase;
}
Override rules could be same as as if the Man extended Bag and as if
Bag extened PencilCase.
**
Martin
Re: More flexible Panel, Fragment, etc.
i really like this. lets commit it. a couple of notes below: assocatedmarkupsourcingstrategy.oncomponenttag() may have a problem. looks like its assuming external markup files begin with wicket:xxx tag, but they may begin with html xmlns:wicket wicket:panel is the html tag stripped before this code executes and the assumption is safe to make? WebMarkupContainerWithAssociatedMarkup is still there, do we need it? it might make sense to merge IMarkupResourceStreamProvider and IMarkupCacheKeyProvider into the sourcing interface so we have one interface that deals with component-markup relationship rather then three. not sure if it makes sense though. if we do this, however, we should probably replace getMarkupSourceStrategy() with a hasMarkupSourceStategy() and newMarkupSourceStrategy() result of which is cached in the metadata - otherwise users have to add another slot to do the caching, know to cache it, know to cache it in a transient field. cheers, -igor On Sun, Jan 9, 2011 at 12:12 AM, Juergen Donnerstag juergen.donners...@gmail.com wrote: done: https://issues.apache.org/jira/browse/WICKET-3314 -Juergen On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: sounds interesting, but your patch didnt make it. attach to a jira issue? -igor On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: Hi, currently every component that requires the markup to be in an associated file must be derived from Panel. Every component that want it's markup inline must be derived from Fragment. I've changed that and moved the respective source code into something I called markup sourcing strategy. I'm not sure it's the best name, so feel free to suggest other names. Such a strategy can be provided to any component via public IMarkupSourcingStrategy getMarkupSourcingStrategy(); Obviously it makes sense that only one strategy can be associated with any component. Each strategy has its own implementations to provide the correct markup, handle the header contribution, necessary changes to the open tag and it renders the component body appropriately. Changing a FormComponent to a FormComponentPanel is now as simple as subclassing getMarkupSourcingStrategy(). And it easily be changed to become a FormComponentFragment I've attached a patch (draft) against 1.5 trunk which successfully passes all tests in core. I wonder what you think about the idea. -Juergen
AbstractRequestWrapperFactory?
Since we provide AbstractRequestWrapperFactory shouldnt it be plugged into wicketfilter somewhere? right now it seems a bit strange that it and its friends are so isolated. -igor
Re: Fragility/Stability of Wicket core
2 - If you want to use Wicket *in Scala*, work on a transparent layer that
sits on top of stock Wicket and adds nice features that would be useful to
the Scala crowd.
I'm already writing all my personal Wicket in Scala. Works well.
On Sun, Jan 9, 2011 at 2:16 PM, Jeremy Thomerson
jer...@wickettraining.comwrote:
On Sat, Jan 8, 2011 at 7:03 PM, richard emberson
richard.ember...@gmail.com
wrote:
Ok, you need to debug whats in a Model when it is added to
a Component. So, in setModelImpl which is called by the
Component constructor you add code to get the object
out of the Model (if its not null, of course) by calling
model.getObject():
void setModelImpl(IModel? model)
{
if (model != null) {
System.out.println(Component.setModelImpl: model.object=+
model.getObject());
}
.
}
Well, just adding this simple code causes a JUnit test to fail.
(And, if you added this debugging a couple of editing cycle prior
to running all the tests, you've got the problem of even knowing
that this is the offending code.)
Why? Give up.
Its because in a Component's constructor the Component has not
yet been added to its parent Component. Thus, the Component's
path only has it as a member. Which means that if the Model
was a ResourceModel, which BTW is wrapped!!!, calling getObject
gets the wrong path for the resource, the resource lookup
fails, and the world ends.
For most folk this is never a problem, even for most developers
because they are making changes to a working Wicket core.
But for me, on the other hand, porting it to Scala where only
bits and pieces worked originally, I ran into this kind of
hidden side effect well, it seemed like all the time, but
it was once and a while ... but it take time to figure out the
issue.
Anyway, amazing that simply asking a model for its inner object
can end the world if you do it at the wrong place.
Ok, all software is fragile like this - one thing wrong that
bang - but it took an hour to find the little innocuous bit of
code.
Not all that amazing. This is happening *during construction* which always
leaves objects in fragile states. It's assumed that you can't start
monkeying around with an object's state until construction is completed
(and
not expect side effects).
[I actually put code, kind of like a constraint, in setModelImpl
to make sure that any model added never had, as an object,
an Option: Some(value) or None; looking for a totally unrelated bug.]
I feel better now, thank you for your time and patience.
Richard
I agree with what others on your scala thread said:
1 - If you want a Scala framework *like* Wicket, start writing Scala code
from the ground up with ideas taken from Wicket. Some code could perhaps
be
ported over in small pieces. But not large sections (or the whole thing
like you're trying).
2 - If you want to use Wicket *in Scala*, work on a transparent layer that
sits on top of stock Wicket and adds nice features that would be useful
to
the Scala crowd.
You have said that your goal is to port java developers to Scala. I'm
interested in trying Scala at some point. I would try either option one or
two above I would prefer two. With it, I get to keep my Wicket
expertise and incrementally add *new hotness* from Scala. I am very
unlikely to try a modified port such as the one you are trying to do. It's
learning a whole new thing all at once, with annoying similarities to
something I know, but inconsistencies that I wouldn't expect.
In my book, 2 is your best bet.
(only my $0.02 in a declining economy)
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Scala-Wicket Help and Advice
Biggest thing I miss in IntelliJ when coding Scala (I write Wicket in Java for my dayjob) is my autocompletion of types. In Java you can type in IModelString foo = new and hit Ctrl + shift + space and it'll provide a list of all types that subclass IModel, but for the time being (IntelliJ 10, build 99.32, Scala plugin 0.4.407) val foo: IModel[String] = new with ctrl + shift + space does nothing. But IntelliJ does a really good job of navigating some of the byzantine Scala code I've been dealing with. (Some people seem to think that every Scala library should be a DSL replete with mysterious operators and where everything happens via implicit conversions nested three types deep. :) It's definitely the best I've seen for Scala, but it's not quite at the Java levels of polish - but then, JetBrains have been working on the Java side of Intellij for 10 versions now. ;) On Sat, Jan 8, 2011 at 10:34 PM, James Carman ja...@carmanconsulting.comwrote: Since scala is statically-typed, the ide can (and does) give you contextual help very easily On Jan 8, 2011 2:21 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: But it will do the right thing about 90% of the time. you'll subconsciously work around 4 or 5% of the rest that doesn't work, and the remaining 5-6% will irritate you. I am used to coding 90% using context help with eclipse (ctrl+space). I am a fast writer but that speeds up my coding by 1000%. Will an IDE do that for scala 90%? I consider context help and quickfix proposals most important for speedy work. - imports sometimes get messed up (relative vs absolute, I hate that in scala) and require a manual correction Import organization is important to me also. I like to spend my time coding logic instead of organizing text files. - analysis is useful about 90% of the time, but it's so slow you may just not care for it What is analysis? I hope it isn't the context help ;) ** Martin - it crashes the JVM on Oracle's JRockit (although IDEA is much faster in that jvm) On Fri, Jan 7, 2011 at 5:37 PM, Liam Clarke-Hutchinson l...@steelsky.co.nzwrote: Define complete. On Sat, Jan 8, 2011 at 7:52 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Nice or complete? ** Martin 2011/1/7 Jonathan Locke jonathan.lo...@gmail.com: Have you checked out IDEA? My Scala friends tell me it has pretty nice Scala support. Jon Less is more. http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/ -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: AbstractRequestWrapperFactory?
I had that idea as well. My initial commit actually included such a hook. But I removed it again. Though wrappers are registered with filters/servlets in the servlet world, wicket already provides a very very easy way by subclassung Application.newRequestxx(). IMO the problem is, and here I agree with you, that it is kind of isolated. It's not obvious. Every dev will first look into WicketFilter but will not find anything. May be something like App.newRequestWrapper() would do as well. -Juergen On Mon, Jan 10, 2011 at 4:39 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: Since we provide AbstractRequestWrapperFactory shouldnt it be plugged into wicketfilter somewhere? right now it seems a bit strange that it and its friends are so isolated. -igor
Re: AbstractRequestWrapperFactory?
what bothers me is that there are isenabled(), supports() methods but nothing that really makes use of them. We can provide a FilterFactoryManager class where users can add filters and it can have a simple Request wrap(Request) method that takes care of isenabled() and supports(). or, we simply remove those from the abstract and let users implement whatever scheme they want. -igor On Sun, Jan 9, 2011 at 10:55 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I had that idea as well. My initial commit actually included such a hook. But I removed it again. Though wrappers are registered with filters/servlets in the servlet world, wicket already provides a very very easy way by subclassung Application.newRequestxx(). IMO the problem is, and here I agree with you, that it is kind of isolated. It's not obvious. Every dev will first look into WicketFilter but will not find anything. May be something like App.newRequestWrapper() would do as well. -Juergen On Mon, Jan 10, 2011 at 4:39 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: Since we provide AbstractRequestWrapperFactory shouldnt it be plugged into wicketfilter somewhere? right now it seems a bit strange that it and its friends are so isolated. -igor
