Github user klopfdreh commented on the pull request:
https://github.com/apache/wicket/pull/120#issuecomment-105766552
Okay, I will investigate it when I got some time left.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
Github user martin-g commented on the pull request:
https://github.com/apache/wicket/pull/120#issuecomment-105766408
Yes. `$` -> vanilla JS.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have th
Github user klopfdreh commented on the pull request:
https://github.com/apache/wicket/pull/120#issuecomment-105766314
You mean the improvements of the comments in here?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If y
Github user martin-g commented on the pull request:
https://github.com/apache/wicket/pull/120#issuecomment-105766171
My shell script for merging GitHub PRs was already in process when
@klopfdreh commented.
@klopfdreh Please apply your improvements in master branch.
@pulse0
Github user asfgit closed the pull request at:
https://github.com/apache/wicket/pull/120
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enab
Good idea - if there would be an automated way - even better! :-)
kind regards
Tobias
> Am 26.05.2015 um 16:03 schrieb Martijn Dashorst :
>
>> On Tue, May 26, 2015 at 3:53 PM, Martin Grigorov
>> wrote:
>> On Tue, May 26, 2015 at 4:16 PM, Martijn Dashorst <
>> martijn.dasho...@gmail.com> wrot
GitHub user pulse00 opened a pull request:
https://github.com/apache/wicket/pull/120
Added DebugBar improvements
- Add `positionBottom` method to position it at the bottom of the screen
- Remember expanded/collapsed state
You can merge this pull request into a Git repository by
Hi,
ok it's finished now. Every stream is going to be closed if readBuffered
is set to true / false. So I think the branch can be merged If no one
does not agree with readBuffered.
https://github.com/apache/wicket/commit/0df9ae2fc97c8e143a5a58330a65b140f85714e3
I tested the playback with Saf
Hi,
ok it's finished now. Every stream is going to be closed if readBuffered
is set to true / false. So I think the branch can be merged If no one
does not agree with readBuffered.
https://github.com/apache/wicket/commit/0df9ae2fc97c8e143a5a58330a65b140f85714e3
I tested the playback with Saf
I don't know the background of this student, but it would be interesting
and definitely more stimulating if she/he could work to a small
parser/translator (using ANTLR or something similar) to scan gdoc
sources and produce the new format.
On 26/05/2015 16:03, Martijn Dashorst wrote:
On Tue, M
On Tue, May 26, 2015 at 3:53 PM, Martin Grigorov wrote:
> On Tue, May 26, 2015 at 4:16 PM, Martijn Dashorst <
> martijn.dasho...@gmail.com> wrote:
>
>> On Tue, May 26, 2015 at 2:46 PM, Martin Grigorov
>> wrote:
>> > I am +1 to move to ASCIIdoctor if:
>> > - the student finds the task interesting
On Tue, May 26, 2015 at 4:16 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> On Tue, May 26, 2015 at 2:46 PM, Martin Grigorov
> wrote:
> > I am +1 to move to ASCIIdoctor if:
> > - the student finds the task interesting to work on
>
> I was going to chain him in the basement until he w
Thank you! I also think it's a good solution.
On 26/05/2015 14:41, Martijn Dashorst wrote:
Done.
On Tue, May 26, 2015 at 2:39 PM, Martijn Dashorst
wrote:
OK, then I'll commit and push.
Martijn
On Tue, May 26, 2015 at 2:37 PM, Martin Grigorov wrote:
This looks handy!
I'm +1 to have it in
On Tue, May 26, 2015 at 2:46 PM, Martin Grigorov wrote:
> I am +1 to move to ASCIIdoctor if:
> - the student finds the task interesting to work on
I was going to chain him in the basement until he was ready (our new
office has a real vault with a 2 feet thick vault door). But your idea
is probabl
Well ok, looking forward to see the single doc PDF export. ;-)
+1 to move to asciidoctor (in a branch till it is finished)
kind regards
Tobias
> Am 26.05.2015 um 14:46 schrieb Martin Grigorov :
>
> I am +1 to move to ASCIIdoctor if:
> - the student finds the task interesting to work on
> - the
I am +1 to move to ASCIIdoctor if:
- the student finds the task interesting to work on
- the build is as easy as now
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 3:42 PM, Martin Grigorov
wrote:
>
> On Tue, May 26, 2015 at 3:37 PM, Martijn
On Tue, May 26, 2015 at 3:37 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> Also, the asciidoctor project has great documentation coming with it
> (I haven't been able to find any documentation regarding the gdoc
> format).
>
http://ci.apache.org/projects/wicket/guide/6.x/guide/contr
Done.
On Tue, May 26, 2015 at 2:39 PM, Martijn Dashorst
wrote:
> OK, then I'll commit and push.
>
> Martijn
>
> On Tue, May 26, 2015 at 2:37 PM, Martin Grigorov wrote:
>> This looks handy!
>> I'm +1 to have it in -core.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.
OK, then I'll commit and push.
Martijn
On Tue, May 26, 2015 at 2:37 PM, Martin Grigorov wrote:
> This looks handy!
> I'm +1 to have it in -core.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, May 26, 2015 at 3:33 PM, Martijn Dashorst <
> martijn
Also, the asciidoctor project has great documentation coming with it
(I haven't been able to find any documentation regarding the gdoc
format).
Martijn
On Tue, May 26, 2015 at 2:36 PM, Martijn Dashorst
wrote:
> Asciidoctor has many build options, including a maven plugin [1].
>
> The default sty
Asciidoctor has many build options, including a maven plugin [1].
The default styling of asciidoctor is much more pleasing to the eye.
The momentum for fixing issues and improving the output format is
great, I rather use living technology than dead technology, and
getting fixes for asciidoctor for
This looks handy!
I'm +1 to have it in -core.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 3:33 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> Using this class I was able to migrate our 7 invocations within a
> couple of minut
Using this class I was able to migrate our 7 invocations within a
couple of minutes.
Martijn
On Tue, May 26, 2015 at 2:32 PM, Martijn Dashorst
wrote:
> So instead of re-introducing the constructors, we could opt to provide
> a utility that makes it easy to refactor code to the new fluent API,
>
On Tue, May 26, 2015 at 3:18 PM, Martin Grigorov
wrote:
> Hi,
>
> I remember an earlier discussion about this change.
> Can you please list what are the benefits?
> One thing I remember is that GDoc is deprecated and Grails community won't
> develop it anymore.
> But the current version seems to
So instead of re-introducing the constructors, we could opt to provide
a utility that makes it easy to refactor code to the new fluent API,
and document its use in the migration guide.
For example:
https://gist.github.com/dashorst/5ae5ebcdedab9da34792
We could create a wicket-migrate-7.x module
Hi,
I would also recommend to stay at gdoc. I also evaluated AsciiDoctor and there
are a lot of formatting and exporting issues to be solved and currently (as
Martin said already) the process is rather simple to update the documentation
and it is well integrated in the build process.
If there
IMO compilation error + better explanation in the migration guide how to
fix the compilation error would be better than reverting to the 6.x
constructors.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 3:09 PM, Martijn Dashorst <
martijn.dash
Hi,
I remember an earlier discussion about this change.
Can you please list what are the benefits?
One thing I remember is that GDoc is deprecated and Grails community won't
develop it anymore.
But the current version seems to work pretty well (Grails 2.4). It is well
integrated with our Maven bui
On Tue, May 26, 2015 at 2:02 PM, Martin Grigorov wrote:
> By reverting the constructors from 6.x we will reintroduce
> https://issues.apache.org/jira/browse/WICKET-4972
In our 1.2M lines of code project, there are only 7 invocations of the
StringResourceModel constructor that I have to figure out
On 26 May 2015 at 14:05:33, Martijn Dashorst (martijn.dasho...@gmail.com) wrote:
The site looks great. That said: we are already (though not
consistently) working on a revamp of our website:
https://dashorst.github.io/wicket-site
Ah, alright, didn’t know that, thanks for the info. The new v
Hi,
Please check:
- https://issues.apache.org/jira/browse/WICKET-3341
- source: https://github.com/dashorst/wicket-site
- demo: http://bitstorm.github.io/wicket-site/
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 2:58 PM, Robert Gründler w
Hi Robert,
The site looks great. That said: we are already (though not
consistently) working on a revamp of our website:
https://dashorst.github.io/wicket-site
You can find the source for that version of the site at
https://github.com/dashorst/wicket-site
This is the site we want to put live at
By reverting the constructors from 6.x we will reintroduce
https://issues.apache.org/jira/browse/WICKET-4972
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, May 26, 2015 at 2:55 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> While trying to fix
All,
At my company we have the option of hiring a temp during the summer
holidays, and one of the things I'd like the temp to do is a migration
of our user manual from GDoc format to ASCIIdoctor.
This is of course, if you would be willing to accept such a format
change, and if the temp is willing
Hi all,
i have used apache wicket since 2010 in multiple projects and i think the
framework
is awesome for a great number of use cases.
However, my (subjective) opinion is that it has a somewhat dusty online
appearance (wicket.apache.org),
including not being responsive for mobile devices.
I’
While trying to fix the resulting compile errors of this change, I
found it hard to decipher what each parameter meant (which is why we
opted going for the fluent interface in the first place)
So take this example for instance:
addColumn(new CustomPropertyColumn(
new StringResourceModel(
36 matches
Mail list logo