jamwiki-devel Mailing List for JAMWiki (Page 4)
Brought to you by:
wrh2
Menu
▾
▴
jamwiki-devel — JAMWiki development mailing list.
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(53) |
Feb
(23) |
Mar
(6) |
Apr
(2) |
May
(5) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(5) |
Mar
(54) |
Apr
(7) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jam...@li...> - 2013-02-23 21:08:54
|
Hi Thomas, Warning fixes are very much appreciated, so long as they're not just "@SuppressWarnings" annotations, which have the side-effect of hiding useful messages. See http://jamwiki.org/wiki/en/How_to_Help#Programmers for the steps needed to get Subversion access to begin committing fixes and creating a branch for the two features you've mentioned. I don't use Eclipse, so it's possible that IDE will report a number of warnings that I wouldn't see otherwise. As to switching to Git, if enough people want to do so then I'm not opposed to the idea. My main issue with Git (vs Subversion) is that with Git it's much easier to screw up your repository in a way that is difficult to undo, such as with funky merges or rebases, while with Subversion you can always just undo the problem commit. We use Git at work, and have had to put a number of processes in place to ensure that people don't do anything that's unexpected and thus cause a lot of work for the repository owner to fix. If there are enough active JAMWiki developers with Git knowledge who can fix any such issues then I'm happy to switch, but if the responsibility is mostly on me to deal with any SCM problems then I'd prefer to continue using Subversion. Again, any thoughts that anyone else has on Git vs. Subversion are welcome - I don't want to stand in the way of people using their preferred SCM tool, but I also don't want to be the only with responsibility for resolving Git-related issues. Ryan On 2/23/2013 11:08 AM, jam...@li... wrote: > Hi, > > I want to learn more about java web development and thus thought I could work > on my issues with jamwiki: > > - I'd like to have diffs in the RecentChanges RSS feed > - I'd like to have email notifications for watched pages > > I already opened three issues about eclipse errors in the jira. Do you also > accept patches to get the number of warnings down? I normally try to keep the > number of warnings near to zero in java projects. > > In eclipse I currently have around 268, mostly: > > - ... is a raw type. References to generic type ... should be parameterized > - The import ... is never used > - The serializable class ... does not declare a static final serialVersionUID > field of type long > - The static ... from the type ... should be accessed in a static way > > Such cleanup work is also a good way to learn more about the codebase. > > By the way: Did I already ask whether you might consider switching to Git? :-) > > A nice ironic blogpost on Git: http://svenpet.com/2013/02/21/dont-use-git > > Regards, > > Thomas Koch, http://www.koch.ro > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Jamwiki-devel mailing list > Jam...@li... > https://lists.sourceforge.net/lists/listinfo/jamwiki-devel > |
|
From: <jam...@li...> - 2013-02-23 19:30:11
|
Hi, I try to run the jamwiki unit tests in eclipse but get 40 errors. The stack trace suggests that those failures are caused by a missing db connection. Could you add a Wiki page in the development section about how to setup the unit tests? "testing"? Thank you, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-02-23 19:08:20
|
Hi, I want to learn more about java web development and thus thought I could work on my issues with jamwiki: - I'd like to have diffs in the RecentChanges RSS feed - I'd like to have email notifications for watched pages I already opened three issues about eclipse errors in the jira. Do you also accept patches to get the number of warnings down? I normally try to keep the number of warnings near to zero in java projects. In eclipse I currently have around 268, mostly: - ... is a raw type. References to generic type ... should be parameterized - The import ... is never used - The serializable class ... does not declare a static final serialVersionUID field of type long - The static ... from the type ... should be accessed in a static way Such cleanup work is also a good way to learn more about the codebase. By the way: Did I already ask whether you might consider switching to Git? :-) A nice ironic blogpost on Git: http://svenpet.com/2013/02/21/dont-use-git Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-02-08 03:30:51
|
Hello, There has been only one bug reported so far against JAMWiki 1.3-beta 2 (fixed by Charles Clavadetscher), so unless other issues are found this may be the final beta release before JAMWiki 1.3 is released. Help testing would be much appreciated (see http://jamwiki.org/wiki/en/Latest_News#JAMWiki_1.3_Beta_2), and for those who can provide translations all languages except for German, Italian and Russian need updating (see http://jamwiki.org/wiki/en/How_to_Help#Translations). I'm going to wait at least another five days to see if any additional issues are found, but barring surprises the next major JAMWiki release will be out very soon. Ryan |
|
From: <jam...@li...> - 2013-01-07 03:23:34
|
Hi All, While it's later than it should be, I've made the first beta release of JAMWiki 1.3 available for download from jamwiki.org: * http://jamwiki.org/download/jamwiki-1.3-beta1.war * http://jamwiki.org/download/jamwiki-1.3-beta1-src.zip * http://jamwiki.org/download/jamwiki-1.3-beta1-src.tar.gz Draft release notes for the JAMWiki 1.3 release can be found at http://jamwiki.org/wiki/en/JAMWiki_1.3 and include a list of features, bug fixes, and installation instructions. While the code has been very stable for me and is currently running on jamwiki.org, remember that this is a BETA release and that it may have issues. For those with time available to help out with the final release, the following would be particularly useful: * Any success/failure reports for installations and upgrades are very valuable and can be reported at http://jamwiki.org/wiki/en/Feedback. In particular, I've done a lot of testing with Postgres and Tomcat but would be interested in hearing what other databases and application servers people have tested the code on and any success/problems they've encountered. * Translation updates would be very helpful. Russian, German and Italian are reasonably complete (thanks guys!), but other languages need attention. See http://jamwiki.org/wiki/en/How_to_Help#Translations for details on getting involved with translations. * Bug reports are HUGELY helpful and can be made at http://jira.jamwiki.org. Specific things to test include the install and upgrade process, the new user preference options, and general wiki functionality. * Finally, any help in improving documentation on jamwiki.org, or even suggestions for improvement, would be greatly appreciated. The code is in feature freeze at this point, and I would expect that the only additional changes to the code will be fixes, minor cleanups, and translation updates. Depending on how many bugs are found in the current code the final JAMWiki 1.3 release should be ready in anywhere from 3-6 weeks. Planning for the JAMWiki 1.4 release is just beginning and can be tracked via http://jamwiki.org/wiki/en/Roadmap. Thanks to all who have contributed to this release and past releases. Cheers, Ryan |
|
From: <jam...@li...> - 2012-08-07 05:41:49
|
Hi All, Please note that following the normal six month release schedule, JAMWiki 1.3 is scheduled for release in October (JAMWiki 1.2 was released in late March). If you've got a feature that you'd like included in the new release please be aware that the next release should go into feature freeze in about one month (at the beginning of September) in order to stabilize the release for an October launch, so please plan your development accordingly. See http://jamwiki.org/wiki/en/Tech:JAMWiki_1.3 for an overview of items currently queued for possible inclusion in the next major release. Cheers, Ryan |
|
From: <jam...@li...> - 2012-05-28 00:12:25
|
Apologies for the delayed response, things have been busy: > - JamWiki looks very solid and usable. Thank you! Thanks! > - The missing Email support is a shock. What's the status? Can I help out? It's been on the TODO list for a while, but it's not a simple change. Implementing a notification system that scales well, doesn't add too much complexity to the code, isn't easy to abuse, and that is configurable for users is a job that has thus far been so big that it has been continually deferred. See http://jamwiki.org/wiki/en/How_to_Help#How_to_contribute for some guidance on how to get involved in updating things. This was discussed some years ago at http://jamwiki.org/wiki/en/Tech:Email but no implementation was ever done. > - The RSS feed links to localhost. What could be the issue? Logged as http://jira.jamwiki.org/browse/JAMWIKI-91 > - It's a pity that there's no diff in the RSS feed I don't personally use RSS, so if there are suggestions for improving things let's discuss - ideally if Mediawiki already has something then send a pointer to their documentation and something similar can likely be done for JAMWiki. > - Is it possible to turn off the virtual wiki support and have all urls without > then /en/ part? This has been frequently requested but I've never tried it. If someone would like to put together some notes on what would need to change then this might be a good change to queue for 1.3.x. > - What parser engine would you recommend for a new Wiki? I've switched it to > Bliki to have the best compatibility with Mediawiki and to have Templates. The default JAMWiki parser provides the best Mediawiki compatibility. The Bliki parser is an alternative parser developed for use with the Bliki engine (http://code.google.com/p/gwtwiki/). Ryan |
|
From: <jam...@li...> - 2012-05-24 05:13:53
|
On 5/23/2012 7:21 AM, jam...@li... wrote: > Now there's a configuration setting "Server URL". Shouldn't the feed servlet > rather use this base URI? I've logged this in JIRA as http://jira.jamwiki.org/browse/JAMWIKI-91. Thanks for the report. Ryan |
|
From: <jam...@li...> - 2012-05-23 14:21:32
|
Hi, as I wrote, my recent changes feed pointed to localhost. This was caused by my proxy setup. The apache web server forwarded the request to localhost:8080 and jamwiki took the information from the request uri to build the feed entry uris. Now there's a configuration setting "Server URL". Shouldn't the feed servlet rather use this base URI? Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2012-05-22 18:06:50
|
jam...@li...: > Hi Thomas, > > I'd be interested in hearing from others, but as someone who has used > Git daily for work for about two years, I'm still not convinced that it > would be superior to Subversion for JAMWiki development. The developer > tools for using Git, particularly on Windows, aren't as strong compared > to Subversion - Tortoise SVN makes Subversion development extremely > easy. In addition, my experience has been that it is far easier to make > mistakes in Git, and far more difficult to track down and undo those > mistakes - for example, a bad rebase and merge can make tracking down > changes hugely confusing. Finally, my experience has been that > co-workers have found Subversion easier to understand than Git. * I haven't used Windows for years, but I thought Git on Windows should be fine since years now. ** Have you seen Github's Git client from yesterday? It's said that even Microsoft helped with the development. Microsoft even offers Git on it's own hosting plattform Codeplex. - The system invented by Linus! :-) http://arstechnica.com/information-technology/2012/05/hands-on-github-for- windows-takes-the-pain-out-of-using-git/ ** EGit for Eclipse is quite powerful. * I made the experience that the best way to fall in love with Git, is to understand its internal data structure. After that you shouldn't have any more problems. There are only four different types of objects: commits, trees, blobs and tags. And you must accept that there's no such thing like a global revision number as in CVS/SVN. http://eagain.net/articles/git-for-computer-scientists ** I wrote some harsh thoughts about projects not moving to Git some time ago. Please excuse the harsh tone, but I think some points might be seen valid: http://www.koch.ro/blog/index.php?/archives/155-Perils-of-not-switching-to- Git.html > On the plus side, Git is far superior when it comes to merges and > branching, and its performance is superior to Subversion, but my > personal opinion is that neither of those advantages outweigh the > aforementioned disadvantages. I think that it's very cumbersome to implement a code review workflow without a good support for quick and cheap branches. And code review is often considered as one of the most important factors for good code. > That said, if enough people feel that moving JAMWiki to Git would be a > preferable solution I wouldn't be opposed, but barring a general > consensus for such a move then I'd be more comfortable staying on > Subversion. Please note that this might be a circular dependency: People that are already using Git might be reluctant to join Jamwiki development. But in the end it's your decision. I can use Git-SVN. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2012-05-22 17:37:24
|
Hi, I've installed jamwiki now at attac-wiki.org First feedbacks, questions, remarks: - JamWiki looks very solid and usable. Thank you! - The missing Email support is a shock. What's the status? Can I help out? - The RSS feed links to localhost. What could be the issue? - It's a pity that there's no diff in the RSS feed - Is it possible to turn off the virtual wiki support and have all urls without then /en/ part? - What parser engine would you recommend for a new Wiki? I've switched it to Bliki to have the best compatibility with Mediawiki and to have Templates. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2012-05-11 03:16:58
|
Hi Thomas, I'd be interested in hearing from others, but as someone who has used Git daily for work for about two years, I'm still not convinced that it would be superior to Subversion for JAMWiki development. The developer tools for using Git, particularly on Windows, aren't as strong compared to Subversion - Tortoise SVN makes Subversion development extremely easy. In addition, my experience has been that it is far easier to make mistakes in Git, and far more difficult to track down and undo those mistakes - for example, a bad rebase and merge can make tracking down changes hugely confusing. Finally, my experience has been that co-workers have found Subversion easier to understand than Git. On the plus side, Git is far superior when it comes to merges and branching, and its performance is superior to Subversion, but my personal opinion is that neither of those advantages outweigh the aforementioned disadvantages. That said, if enough people feel that moving JAMWiki to Git would be a preferable solution I wouldn't be opposed, but barring a general consensus for such a move then I'd be more comfortable staying on Subversion. Ryan On 5/10/2012 6:52 AM, jam...@li... wrote: > Hi, > > I already asked this question in July last year, whether there is interest of > switching the development of Jamwiki to Git. I just wanted to ping, whether > anything has changed since then? > > I'm currently evaluating Jamwiki again and one important point for me to > choose any software is the sanity of the development process. Using a DVCS, > especially Git, is one major point in that category. > > If I should choose Jamwiki, I'll most probably also package it for Debian > which would also be a lot easier, if the source were available in Git. > > Thank you for the software and any reply, > > Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2012-05-10 13:53:08
|
Hi, I already asked this question in July last year, whether there is interest of switching the development of Jamwiki to Git. I just wanted to ping, whether anything has changed since then? I'm currently evaluating Jamwiki again and one important point for me to choose any software is the sanity of the development process. Using a DVCS, especially Git, is one major point in that category. If I should choose Jamwiki, I'll most probably also package it for Debian which would also be a lot easier, if the source were available in Git. Thank you for the software and any reply, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2012-03-15 04:05:26
|
The third (and hopefully final) beta release for JAMWiki 1.2 is now available for download from jamwiki.org: * http://jamwiki.org/download/jamwiki-1.2-beta3.war * http://jamwiki.org/download/jamwiki-1.2-beta3-src.zip * http://jamwiki.org/download/jamwiki-1.2-beta3-src.tar.gz Draft release notes for the JAMWiki 1.2 release can be found at http://jamwiki.org/wiki/en/JAMWiki_1.2 and include a list of features, bug fixes, and installation instructions. PLEASE help out by installing and testing this release. If you speak multiple languages then translation updates would also be greatly appreciated - see http://jamwiki.org/wiki/en/How_to_Help#Translations. Ryan |
|
From: <jam...@li...> - 2012-02-23 03:14:51
|
It's a bit later than planned, but the second beta release for JAMWiki 1.2 is now available for download from jamwiki.org: * http://jamwiki.org/download/jamwiki-1.2-beta2.war * http://jamwiki.org/download/jamwiki-1.2-beta2-src.zip * http://jamwiki.org/download/jamwiki-1.2-beta2-src.tar.gz Draft release notes for the JAMWiki 1.2 release can be found at http://jamwiki.org/wiki/en/JAMWiki_1.2 and include a list of features, bug fixes, and installation instructions. If anyone is able to contribute translation updates for this release please see http://jamwiki.org/wiki/en/How_to_Help#Translations. As always testing and feedback is greatly appreciated. Barring surprises I expect that there will be one more beta release before the final release of JAMWiki 1.2. Ryan |
|
From: <jam...@li...> - 2012-02-05 22:15:53
|
Hi All, It's been five months since the release of JAMWiki 1.1, and in order to meet the six-month release schedule I've made the first beta release of JAMWiki 1.2 available for download from jamwiki.org: * http://jamwiki.org/download/jamwiki-1.2-beta1.war * http://jamwiki.org/download/jamwiki-1.2-beta1-src.zip * http://jamwiki.org/download/jamwiki-1.2-beta1-src.tar.gz Draft release notes for the JAMWiki 1.2 release can be found at http://jamwiki.org/wiki/en/JAMWiki_1.2 and include a list of features, bug fixes, and installation instructions. While the code has been very stable for me and is currently running on jamwiki.org, remember that this is a BETA release and that it may have issues. For those with time available to help out with the final release, the following would be particularly useful: * Any success/failure reports for installations and upgrades are very valuable and can be reported at http://jamwiki.org/wiki/en/Feedback. In particular, I've done a lot of testing with Postgres and Tomcat but would be interested in hearing what other databases and application servers people have tested the code on and any success/problems they've encountered. * Translation updates would be very helpful. Russian and German are reasonably complete (thanks shar and Axel!), but other languages need attention. See http://jamwiki.org/wiki/en/How_to_Help#Translations for details on getting involved with translations. * Bug reports are HUGELY helpful and can be made at http://jira.jamwiki.org. Specific things to test include the install and upgrade process, the new file storage options, and general wiki functionality. * Finally, any help in improving documentation on jamwiki.org, or even suggestions for improvement, would be greatly appreciated. The code is in feature freeze at this point, and I would expect that the only additional changes to the code will be fixes, minor cleanups, and translation updates. Depending on how many bugs are found in the current code the final JAMWiki 1.2 release should be ready in anywhere from 3-6 weeks. Planning for the JAMWiki 1.3 release is just beginning and can be found at http://jamwiki.org/wiki/en/Tech:JAMWiki_1.3. Thanks to all who have contributed to this release and past releases. Cheers, Ryan |
|
From: <jam...@li...> - 2012-01-21 19:27:55
|
Thanks for the feedback. Regarding the enhancements, there are some limitations imposed by JFlex, most notably that patterns must be known at compile time rather than run time. It's for this reason that custom tags must be HTML-like (the JFlex parser can then look for an HTML tag pattern), and also why the </__NOPARSE> tag pattern was hard-coded (Note that </__NOPARSE> can only be used internally - if an end-user tried to include that pattern in a wiki topic it would be parsed just like any other invalid HTML). Regarding your comment about adding four custom tag methods for use of custom tags during different iterations of the parser, it's definitely something that's doable, but in order to avoid a severe performance penalty the implementation would require modifying the code that currently handles HTML tags in the jamwiki-processor parser to check for custom tags. Unfortunately that's a big change that I'd be uncomfortable including in JAMWiki 1.2 (which is nearly at the end of its development cycle), so it would need to be considered for JAMWiki 1.3. And note that custom tags can already access metadata, topic name, etc via the lexer.getParserInput() and lexer.getParserOutput() methods of the lexer object that is passed to the tag during parsing. Let me know if you'd like write access to Subversion in order to be able to create your own development branch as it's often easier to have these discussions when there is code to discuss. Alternately, I'll be interested to see any tags that are developed when you are ready to release them. Cheers, Ryan On 1/19/2012 10:26 PM, jam...@li... wrote: > Wow! How quick! > > Your correct the implementation you explained would allow me to do > what I am thinking now to do. However there are a few enhancements, > which I think would make this feature even more flexible and > powerful: > > I don't know JFlex enough to say if this would be too complex, but if > you can make it aware of Custom Tags on all iterations and call > different methods for each iteration, then Custom Tag class could > include in the output the same (or different) Custom Tag to be > handled by later iterations. If the whole conversion get completed in > the early iterations, then the class won't insert its Custom Tag and > later iterations won't even call the methods. In order to do that all > methods should receive the tag name as a parameter in addition to the > attributes and inner-text. > > In addition the special methods of all Custom Tag classes should be > called before start parsing the topic and different ones after > finishing. > > All this would allow implementation using Custom Tag functionality > like TOC or references. > > Also would be nice to allow Custom Tag class methods to be able to > access the environment like Name of the Page, User, created the > topic, when it was created, same for last update, may be whole > history, etc. > > Because of what I suggested the Custom Tag class would need to > implement many methods (at least 4) the based class would be helpful > with default implementations. Before First and After Last methods > wouldn't have attributes or text to convert and default > implementation would be empty. The parse to HTML method would copy > the text into its output, but the rest of the methods would take > attributes, text and tag name and return the text, surrounded in the > tag with attributes. > > In the mean time I am working on a couple Custom Tag classes of my > own, which I think would be helpful. > > > > CAB |
|
From: <jam...@li...> - 2012-01-20 16:03:03
|
Wow! Quick and very good job. Sorry I didn't get any mail from the mailing list :-/
Otherwise I would respond sooner.
So this is my few comments as you requested.
First of all you are correct this implementation is good enough to provide everything I am looking for now. However by doing some thing slightly different you can make feature even more flexible and powerful.
In general I prefer to avoid hardcoded string. In this case "<__NOPARSE>". Another solution would eliminate need to alter step 1. Also no hardcoded tag would free it to be used in other places and minimize the confusion around the tag which MUST NOT BE USED! The error message would be something like "The tag <__NOPARSE> has no real usage in the Wiki text, but can not be used for any purpose anyway".
Parser should remove the Custom Tag and replace it (tag and content) with text, returned from the method call. I don't know JFlex enough to say how difficult it would be, but if you can include Custom Tag parsing in all steps (every time calling different method) the system would be most flexible. Template parsing would allow to define new syntax for templates. Same true for metadata parsing and to HTML conversion.
The Custom Tag class should be able to insert the same custom tag in its output. To allow this the call to the parse...() methods should include additional parameter for the tag name.
Default implementation (which can be used to override just 1 of these methods) would echo into output the input text included into custom tag. Only parse2Html(...) will include text without tag. A bit faster implementation of this base class would return empty strings. In this case the default behavior would make parser to skip custom tags in later steps, and would require developer to override all methods up to one s/he actually needs.
So my proposed methods would be like:
public class CustomTagBase {
public String parseTemplate(String tag, String text) { return keepTag(tag, text);}
public String parseMetadata(String tag, String text) { return keepTag(tag, text);}
public String parse2Html(String tag, String text) { return text;}
protected final String keepTag(String tag, String text) { return "<"+tag+">"+text+"</"+tag+">";}
}
Can this be done in time for v.1.2? This would be great.
I can send to you the default implementation of the Custom Tag implementing class. Also I am working on some useful implementations for this feature.
Sent from my iPad
|
|
From: <jam...@li...> - 2012-01-20 06:27:04
|
Wow! How quick! Your correct the implementation you explained would allow me to do what I am thinking now to do. However there are a few enhancements, which I think would make this feature even more flexible and powerful: I don't know JFlex enough to say if this would be too complex, but if you can make it aware of Custom Tags on all iterations and call different methods for each iteration, then Custom Tag class could include in the output the same (or different) Custom Tag to be handled by later iterations. If the whole conversion get completed in the early iterations, then the class won't insert its Custom Tag and later iterations won't even call the methods. In order to do that all methods should receive the tag name as a parameter in addition to the attributes and inner-text. In addition the special methods of all Custom Tag classes should be called before start parsing the topic and different ones after finishing. All this would allow implementation using Custom Tag functionality like TOC or references. Also would be nice to allow Custom Tag class methods to be able to access the environment like Name of the Page, User, created the topic, when it was created, same for last update, may be whole history, etc. Because of what I suggested the Custom Tag class would need to implement many methods (at least 4) the based class would be helpful with default implementations. Before First and After Last methods wouldn't have attributes or text to convert and default implementation would be empty. The parse to HTML method would copy the text into its output, but the rest of the methods would take attributes, text and tag name and return the text, surrounded in the tag with attributes. In the mean time I am working on a couple Custom Tag classes of my own, which I think would be helpful. CAB |
|
From: <jam...@li...> - 2012-01-08 22:05:43
|
Hi All, JAMWiki 1.1 was released on 30-Aug-2011, which means that following the normal six-month schedule, JAMWiki 1.2 is due in late-February / early-March. If anyone on this list was planning on making any changes or working on any new features please note that all feature work for JAMWiki 1.2 should be finished no later than the end of January, with February then spent ensuring that the code is as bug-free as possible prior to the final release. For an overview of changes in JAMWiki 1.2 please see http://jamwiki.org/wiki/en/Tech:JAMWiki_1.2 as well as the CHANGELOG.txt file in trunk. Ryan |
|
From: <jam...@li...> - 2012-01-06 05:53:33
|
The following changes have been recently committed:
* Revision 3920 supports configuration of the tag name from the
jamwiki-configuration.xml file as previously discussed.
* Revision 3923 adds support for <__NOPARSE> as described in the
previous email.
* Revision 3924 implements extension tags for iframe, Facebook
"like" buttons, and Twitter "tweet" buttons.
This code is still a work in progress, and not something that I'm 100%
sure will be the long term solution, but I'm going to try this out on a
couple of sites I operate to see how things work out.
Feedback would be appreciated. One enhancement I'd like to make is to
allow configuration parameters to be passed in when initializing tags so
that (for example) the Facebook tag could be configured to ignore any
URL that pointed to an external site, or tags could be marked as valid
for use on only a specified list of topics. I'm also not thrilled with
using jamwiki-configuration.xml to manage this functionality, so that
may also change in time.
Again, any feedback would be great - let me know if this meets your
needs, if there is an alternative that you feel would be cleaner, or if
there are still limitations that require addressing.
Ryan
On 1/4/2012 10:13 AM, Ryan Holliday wrote:
> Hello,
>
> On 1/3/2012 10:21 PM, jam...@li... wrote:
> > I see the Custom Tag initial implementation and realized that this is
> > what I was looking for.
>
> While I have high hopes for the custom tag implementation, it is fairly
> new and not entirely complete, so there are no doubts it needs
> improvement - while trying to add support for an <iframe> custom tag and
> a custom tag to add social media buttons I've hit the same issues you've
> described.
>
>> First of all I don't thing that the name of the tag should be hardcoded
>> in the Java. This may cause the name conflict if 2 different custom tag
>> classes would use the same name. Instead the name should be configured
>> in the jamwiki-configuration.xml file along side with Java class.
>
> This would be an easy change and I can try to get something committed to
> trunk today.
>
>> Second. The parce(...) method converts Wiki text inside custom tag into
>> Wiki text to replace that tag. This is obviously useful in some cases
>> (like <gallery> tag), but limited. On one hand the replacement is done
>> after template substitution, so the replacing Wiki text should be final
>> and can not use any shortcuts (like templates). On another hand
>> replacing Wiki text with HTML fragment is still subject for Wiki
>> configuration and limitations in terms of supported HTML tags.
>
> While I generally like the JFlex lexer, it has made custom tags
> difficult. Currently the parser does several passes when parsing:
>
> 1. Parse templates.
> 2. Parse custom tags.
> 3. Parse metadata.
> 4. Parse to HTML.
> 5. Post process (add TOC, references, etc).
>
> As you've noted, a current limitation of custom tags is that they must
> emit syntax that will not later be escaped by another parsing pass. The
> parse2HTML(...) solution you've proposed would be a good one, but there
> would need to be a way to specify that a fragment should not be further
> parsed. I was thinking of something similar, basically:
>
> * Make step four ("Parse to HTML") aware of custom tags, so that
> rather than escaping them they are treated as valid parser input.
> * This could be done in a few ways, the simplest of which might just
> be to allow custom tags to implement a "no parse" directive that
> works similar to "<nowiki>". Thus a custom iframe tag might
> generate output similar to "<__NOPARSE><iframe... /></__NOPARSE>"
> to indicate that the content inside of the "__NOPARSE" tags should
> be ignored. Obviously the "__NOPARSE" tags would need to be
> stripped in step 5, and input would need to be examined in step 1
> to ensure that this functionality was not abused by malicious users.
>
> I think that would meet your needs as well as my own - a custom tag (or
> any other parser code) could explicitly output text that would not be
> parsed further, allowing output as HTML, Javascript, etc. However, the
> existing parser rules would not be violated. I may try to put some test
> code together this afternoon to determine if this approach is feasible,
> but please let me know your thoughts as I haven't spent enough time on
> this idea that I'm confident it will meet all requirements.
>
> Ryan
>
|
|
From: <jam...@li...> - 2012-01-04 18:13:59
|
Hello,
On 1/3/2012 10:21 PM, jam...@li... wrote:
> I see the Custom Tag initial implementation and realized that this is
> what I was looking for.
While I have high hopes for the custom tag implementation, it is fairly
new and not entirely complete, so there are no doubts it needs
improvement - while trying to add support for an <iframe> custom tag and
a custom tag to add social media buttons I've hit the same issues you've
described.
> First of all I don't thing that the name of the tag should be hardcoded
> in the Java. This may cause the name conflict if 2 different custom tag
> classes would use the same name. Instead the name should be configured
> in the jamwiki-configuration.xml file along side with Java class.
This would be an easy change and I can try to get something committed to
trunk today.
> Second. The parce(...) method converts Wiki text inside custom tag into
> Wiki text to replace that tag. This is obviously useful in some cases
> (like <gallery> tag), but limited. On one hand the replacement is done
> after template substitution, so the replacing Wiki text should be final
> and can not use any shortcuts (like templates). On another hand
> replacing Wiki text with HTML fragment is still subject for Wiki
> configuration and limitations in terms of supported HTML tags.
While I generally like the JFlex lexer, it has made custom tags
difficult. Currently the parser does several passes when parsing:
1. Parse templates.
2. Parse custom tags.
3. Parse metadata.
4. Parse to HTML.
5. Post process (add TOC, references, etc).
As you've noted, a current limitation of custom tags is that they must
emit syntax that will not later be escaped by another parsing pass. The
parse2HTML(...) solution you've proposed would be a good one, but there
would need to be a way to specify that a fragment should not be further
parsed. I was thinking of something similar, basically:
* Make step four ("Parse to HTML") aware of custom tags, so that
rather than escaping them they are treated as valid parser input.
* This could be done in a few ways, the simplest of which might just
be to allow custom tags to implement a "no parse" directive that
works similar to "<nowiki>". Thus a custom iframe tag might
generate output similar to "<__NOPARSE><iframe... /></__NOPARSE>"
to indicate that the content inside of the "__NOPARSE" tags should
be ignored. Obviously the "__NOPARSE" tags would need to be
stripped in step 5, and input would need to be examined in step 1
to ensure that this functionality was not abused by malicious users.
I think that would meet your needs as well as my own - a custom tag (or
any other parser code) could explicitly output text that would not be
parsed further, allowing output as HTML, Javascript, etc. However, the
existing parser rules would not be violated. I may try to put some test
code together this afternoon to determine if this approach is feasible,
but please let me know your thoughts as I haven't spent enough time on
this idea that I'm confident it will meet all requirements.
Ryan
|
|
From: <jam...@li...> - 2012-01-04 07:22:11
|
I see the Custom Tag initial implementation and realized that this is what I was looking for. However when I read more about current implementation I realized that IMHO it should work differently. So let discuss... First of all I don't thing that the name of the tag should be hardcoded in the Java. This may cause the name conflict if 2 different custom tag classes would use the same name. Instead the name should be configured in the jamwiki-configuration.xml file along side with Java class. This way the site administrator will be responsible for naming custom tags and can avoid conflict. Second. The parce(...) method converts Wiki text inside custom tag into Wiki text to replace that tag. This is obviously useful in some cases (like <gallery> tag), but limited. On one hand the replacement is done after template substitution, so the replacing Wiki text should be final and can not use any shortcuts (like templates). On another hand replacing Wiki text with HTML fragment is still subject for Wiki configuration and limitations in terms of supported HTML tags. I am not argue agains current parse(...) method, but suggesting to extend the interface with parse2HTML(...) method, which will insert HTML fragment directly into the final document. It should be called later in the parsing process and produced output should not be modified any more. This would allow to develop Custom Tag to convert Wiki text directly into HTML. For example nowadays more and more browsers support HTML5. I am planning to develop Custom Tag to include SVG images into the Wiki. The source text would follow basic JAMWiki syntax (more or less), but Java class behind Custom Tag will convert it into SVG (which is XML) and need to insert it into the page. Another application of this could be Custom Tag to convert ASCIIMath into MathML (which is also XML and part of HTML5). This would allow many different customizations without changing the core code. For example special Custom Tag can generate the HTML form for user to fill (I don't think this functionality is available now). What do you think? I don't know how much more difficult to implement this would be, but it will provide a huge flexibility for the whole system. Thanks CAB |
|
From: <jam...@li...> - 2011-12-20 05:54:50
|
Hi All, As part of the development for JAMWiki 1.2 I've been trying to make it easier to customize the look & feel of JAMWiki. Thus far code has been committed to: * Add a JAMWiki:Header topic for adding custom header text to all pages * Split the current "StyleSheet" CSS topic into "JAMWiki:System.css" (read-only for core CSS, will be upgraded with new core styles after major releases) and "JAMWiki:Custom.css" (editable, to allow customizations by site owners, will never be modified by upgrades) * Move some previously-hard-coded HTML to template files so that look and feel can be tweaked without requiring a re-compile. One area that I would like to get some feedback on is how best to allow custom code to be inserted in the document's <head> tag, such as <meta> tags, <script> tags, etc. I looked through the Mediawiki docs on this subject, and they don't have a particularly elegant solution, so I'd be interested in suggestions. I'd like it to be easy for a site to (for example) include JQuery or add Facebook meta tags, and the options I was considering are: 1. Add a text block that admins can edit via Special:Admin that will simply be copied verbatim into the document <head>. This is flexible, but will break page rendering if the HTML syntax is wrong. 2. Add an editable wiki topic (admin-only permission) that does the same as #1, and has the same downside as #1. 3. Add new JAMWiki:System.js and JAMWiki:Custom.js system topics that hold Javascript, similar to the current CSS topics. To support custom <meta> tags, a key-value entry tool could be built in the Special:Admin interface. 4. ??? I've been giving this some thought for a while now and haven't come up with a solution that I'm happy with, so any suggestions from the people on this list, and ideally pointers to any other projects that have implemented this type of functionality in an elegant way, would be much appreciated. Ryan |
|
From: <jam...@li...> - 2011-09-16 01:34:56
|
Hello, Following the normal one month cycle for minor releases, JAMWiki 1.1.1 is scheduled for release in 1-2 weeks. If anyone has any translation updates please either use the http://jamwiki.org/wiki/en/Special:Translation tool or commit them to the 1.1.x branch in Subversion. Additionally, any bug reports should be made as soon as possible so that there is time to address them for this release. JAMWiki 1.2 development is underway and the planning document is available at http://jamwiki.org/wiki/en/Tech:JAMWiki_1.2. Following the six month development cycle for major releases, the goal will be to finish this release by late February or early March. If anyone has a specific feature they would like to implement or see implemented it would be great to start work as early as possible, so please use this mailing list or jamwiki.org for discussion. Ryan |
