improving default XTF interface

[Hillel Arnold]

Hi everyone!

I'm working on a project to spin up a new XTF instance for a somewhat local consortium. We've spent a fair amount of time improving the interface (I hope I'm not stepping on anyone's toes, but the default UI is pretty ugly and not very web standards compliant), implementing Bootstrap, getting rid of some of the copious HTML tables and moving the document pages out of frames. This seems like work that might benefit the larger community. I was thinking about going all the way with this and creating a fork of the repo that can be used as a better place for new adopters to start, but before I did that I had a couple questions.

1. Does this sound like a good idea? Is there actually a need for something like this?

2. What's the development timeline for XTF. If there is a new release planned soon, I'd hold off until that code is out so I don't have to worry about merging in changes later.

3. Is this something that could be merged into the master repo for XTF, or is it better if this lives on its own?

I'd be interested in hearing any thoughts on any of these questions!

Hillel

[Jasper Bedaux]

Hi Hillel,

We (at the library of the University of Amsterdam) are certainly interested. I was discussing with a colleague almost exactly the same things you mention, so we hope your work can be merged into the master repo of XTF.

In addition, we are thinking about some other improvements that are related to the interface of XTF. Maybe we can even combine some things or work together, or maybe it is better if we do things separately (since I understand you already did a lot of work and we are not this far yet).

Things we would like to improve:

1. Better internationalization / translation mechanism (the current search/replace mechanism sometimes translates words where it shouldn't and it is hard to have different translations of the same word in different contexts).

2. Easier configuration of extra metadata fields: I don't know if others do this too, but for most collections we add custom metadata fields, that we add to

 - Search results

 - Search form

 - Facets

 - Sort option (sometimes)

 - Browse by ... (sometimes)

In the current situation, for this to work, code needs to be copied/pasted/changed at multiple places in multiple files. We would like to have a configuration file, in which one would be able to specify all this information (name, display name, if and how to show the field as facet, on search form etc.) and then the code for generating facets, search form, search results etc. would read this from the configuration file instead of using hard coded instructions.

If others are interested in this too, let me know, then we will try to make some more detailed design for this and put it on the mailing list so others can comment before we implement anything.

3. (Maybe, if others are interested): move some interface settings into a config file like number of search results per page, components to show/hide etc.

Of course any comments or input is welcome!

Jasper

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Scott Ziegler]

Hillel,

I can only speak to your first question ("Does this sound like a good idea? Is there actually a need for something like this?"):

I think this would be great. We love XTF here at the APS, but we (I, at least) struggle with the HTML tables in the interface.

Should you need a hand with testing, prototyping, etc. I think this is a worthy endeavor.

-Scott

Scott Ziegler, MA, MSLIS, CA
Assistant Head of Technology/Web Development Librarian
American Philosophical Society
105 South 5th Street
Philadelphia, PA 19106
Telephone: 215.599.4299
Email: szie...@amphilsoc.org

[Bridger Dyson-Smith]

Hi all, 

A quick reply as I'm mobile at the moment - I've done some work on TEI and EAD frameless layouts. I'm still in the process of working out CSS for the new layout but I would be delighted to share the work I've done so far. It's rough and unfinished (and limited to just two of the delivery types) but it may be a helpful starting point.

Let me know if there's interest and I can add people to the bitbucket repository.

Best,

Bridger

--

University of Tennessee Libraries

Digital Initiatives

[Conal Tuohy]

I've made some generic TEI additions to the TEI display XSLT (docFormatter) to include support for various phrase-level elements, which I'd also like to share.

The changes were to needed to publish a manuscript that contained a lot of shorthand, misspellings, and corrections.

Concretely, the changes are so that if a tei:choice contains both a tei:abbrev and a tei:expan, or both a tei:sic and a tei:corr, then only the expansion or correction is shown. I don't know if that behaviour would be seen as a good default, but if so, I'd love to contribute it.

I also added renderings of tei:unclear, tei:sic, and tei:gap, and for completeness I should really add tei:supplied (although my text doesn't use that).

Does that sound useful?

Regards

Con

[Hillel Arnold]

Wondering if someone from CDL wants to chime in here. It sounds like there's a lot of interest from the community in contributing back code and enhancements to XTF, but unless I'm missing something, it doesn't seem like there's a way to do that.

[Lisa Schiff]

HI Everyone,

 Martin was off at a conference all last week, which is why you haven't seen him on the list for a bit, but we at the CDL are all very excited by the recent increased interest in contributing code.  We'll be sending out a Doodle Poll next week to schedule a call for anyone who would like to talk about how that could work most easily and effectively for all concerned, so keep an eye out for that message.

Thanks,
Lisa

Lisa Schiff

Technical Lead

Access & Publishing Group

California Digital Library
University of California
Office of the President
415 20th Street, 4th Floor
Oakland, CA 94612-2901

510-987-0881 (t) 510-893-5212 (f)

http://orcid.org/0000-0002-3572-2981

 

Follow eScholarship on Facebook and Twitter

 

..

[BT]

I'd just like to make a few observations (FYI, I'm in the same sub-group as Lisa, Kirk, and Martin, but I'm not in the same sub-sub-group as XTF)

There are basically three types of changes to XTF.

1. core java code

2. core XSLT code

3. custom to your app XSLT (not everyone does this)

4. custom to your app HTML/CSS (one should be able to change this w/o getting deep into the XSLT)

5. new features (such as an image zoomer)

The way a lot of people use XTF, they just start hacking on the XSLT, sometimes just starting from the tutorial or the .  Then, eventually they check that into revision control or maybe they just keep un-packing new .jar files in there working directory.

In my XTF projects, I keep a branch for my project; and then every year or so I pull in the upstream changes from the main XTF repo and branch and merge them into my repo and branch.  My fear is that if changes get too radical into class 2 code (and the line between type 2 and type 3 is blurry) that it will make it hard to merge upstream changes.

I have also for a long time felt a tension about the role of the default XSLT.  I think Kirk and I agree that these were not really meant to be used -- these were sort of a demo "hello world" app.  It is clear that there is a need for an "out of the box" XTF that looks like it was designed during this decade.  If we tackle that, maybe we can come up with a better workflow for maintaining local changes and customizations.

I think a new UI should use van der vlist style free XSLT style.  This would make it easy for users to customize.

http://eric.van-der-vlist.com/blog/2006/06/02/2368_the_influence_of_microformats_on_style-free_stylesheets/

To keep the line between type 2 and type 3 changes sharp, I wonder if there is a way to implement something like rails or django where -- rather than editing core files -- you copy files you want to edit to a directory to override changes.  Then, somehow document() and xsl:include would know to first look for the file in the local customized directory; and if it is not there it would look in the core place for the file?

Should the default XTF be "kitchen sink" style with some of everything?  At some point I'd like to merge a SNAC/EAC branch into the main XTF.  Would it work to have this in a branch, or should default branch have support for everything.

Less radical than re-working XTF customization -- one way might be to maintain the original default branch and a "new-ui" branch with this work -- and at some point just switch default to "legacy" and new-ui to default.

[Bridger Dyson-Smith]

On Wed, Apr 2, 2014 at 12:00 PM, BT <brian.tingl...@gmail.com> wrote:

I'd just like to make a few observations (FYI, I'm in the same sub-group as Lisa, Kirk, and Martin, but I'm not in the same sub-sub-group as XTF)

There are basically three types of changes to XTF.

1. core java code

2. core XSLT code

3. custom to your app XSLT (not everyone does this)

4. custom to your app HTML/CSS (one should be able to change this w/o getting deep into the XSLT)

5. new features (such as an image zoomer)

The way a lot of people use XTF, they just start hacking on the XSLT, sometimes just starting from the tutorial or the .  Then, eventually they check that into revision control or maybe they just keep un-packing new .jar files in there working directory.

In my XTF projects, I keep a branch for my project; and then every year or so I pull in the upstream changes from the main XTF repo and branch and merge them into my repo and branch.  My fear is that if changes get too radical into class 2 code (and the line between type 2 and type 3 is blurry) that it will make it hard to merge upstream changes. 

I agree with Brian. It'd be nice to keep things in type 3 (and 4), but I confess that I'm not entirely sure where the line falls between 2 and 3. Would 2 be everything under style/* except dynaXML?

 

I have also for a long time felt a tension about the role of the default XSLT.  I think Kirk and I agree that these were not really meant to be used -- these were sort of a demo "hello world" app.  It is clear that there is a need for an "out of the box" XTF that looks like it was designed during this decade.  If we tackle that, maybe we can come up with a better workflow for maintaining local changes and customizations.

I think a new UI should use van der vlist style free XSLT style.  This would make it easy for users to customize.

http://eric.van-der-vlist.com/blog/2006/06/02/2368_the_influence_of_microformats_on_style-free_stylesheets/

This is essentially the approach that I've (tried to) use in the most recent customization work. 

 

To keep the line between type 2 and type 3 changes sharp, I wonder if there is a way to implement something like rails or django where -- rather than editing core files -- you copy files you want to edit to a directory to override changes.  Then, somehow document() and xsl:include would know to first look for the file in the local customized directory; and if it is not there it would look in the core place for the file?

This is a Really Interesting Idea - thanks for mentioning it. 

 

Should the default XTF be "kitchen sink" style with some of everything?  At some point I'd like to merge a SNAC/EAC branch into the main XTF.  Would it work to have this in a branch, or should default branch have support for everything.

I'd make a vote for including SNAC/EAC support in the default branch, maybe with some method for disabling it (e.g. "comment out these lines of code" or something). I think it's always nice to be able to say "XTF does that" and then give a demo. If the UI were a bit more modern I would probably cringe a bit less when I did this sort of thing. :)

 

Less radical than re-working XTF customization -- one way might be to maintain the original default branch and a "new-ui" branch with this work -- and at some point just switch default to "legacy" and new-ui to default.

  

The working plan for us - still unfinished - was to work on local customizations, then generalize those changes back to XTF core (with guidance from Martin and Kirk). Again, if anyone is interested in taking a look at the work that's been done here please let me know and I'll work out how to add you to the repository.

Cheers,
Bridger

[Hillel Arnold]

When I started this thread, I was mostly thinking along the lines of HTML/CSS improvement which, as Brian says, can be accomplished without modifying "core" (whatever that is) XSLT. I know that dealing with all the various docFormatters is probably the bulk of the work, but I think even just improving the crossQuery pages (specifically the ones produced by resultFormatter stylesheets) would be a huge step in the right direction.

+1 for Brian's idea of specific customization directories as well as default support for EAC.

Bridger, I'd be interested in taking a look at what you've done, so if are able to get me access to the repo, that would be great!

--

[Martin Haye]

This level of enthusiasm and the number of people jumping in is very exciting! There's a strong consensus that the default XTF interface needs refactoring and a facelift. Yes!

I've been hesitant to jump in today because I have a conflicting worry that everybody working in different directions will result in chaos. But you know what? That's me overthinking things, and trying to control things could kill people's enthusiasm.

So I'd say: each of you go ahead and fork the code. Put in some of your ideas and share it with us. We can worry later about how to roll it all back together into a new release of XTF.

Specific points I should address:

- Timeline for XTF 3.2 is, um, whenever somebody needs it? There are a few bug fixes in the Java code that need to get released, and that's about it. If you think we should release it, let's release it.

- For easier forking we could move the main source code repo from SourceForge to BitBucket or Github. Or both. Preferences?

- I think we should continue our longstanding method of keeping the Java code backward compatible, and not worryingl about keeping the XSLT in its same structure. While I favor dividing the XSLT into core layer vs. UI layer, it's currently not divided that way; switching to that will be a deep change and it won't be feasible to merge that code into implementations based on the old code. So be it IMO.

And my own +1's (in no particular order)

+1 better internationalization

+1 easier configuration of extra metadata fields

+1 replace tables with divs

+1 no frames

+1 Bootstrap

+1 community code incorporated into XTF!

+1 style-free XSLT

+1 EAC support

+1 separating concerns into layers

Finally I'd add a couple things:

- Could somebody rip out YUI and replace it with jQuery?

- I'd love to see somebody make a Rails or Django or AngularJS front-end as an alternative to XSLT UI code. It would just pass raw XML back and forth to stub XSLT running in XTF.

--Martin

On Wed, Apr 2, 2014 at 11:16 AM, Hillel Arnold <hillel...@gmail.com> wrote:

When I started this thread, I was mostly thinking along the lines of HTML/CSS improvement which, as Brian says, can be accomplished without modifying "core" (whatever that is) XSLT. I know that dealing with all the various docFormatters is probably the bulk of the work, but I think even just improving the crossQuery pages (specifically the ones produced by resultFormatter stylesheets) would be a huge step in the right direction.

+1 for Brian's idea of specific customization directories as well as default support for EAC.

Bridger, I'd be interested in taking a look at what you've done, so if are able to get me access to the repo, that would be great!

On Wed, Apr 2, 2014 at 1:02 PM, Bridger Dyson-Smith <bdyso...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Hillel Arnold]

Hi Martin,

Thanks for jumping in! 

 

- For easier forking we could move the main source code repo from SourceForge to BitBucket or Github. Or both. Preferences?

I'm a Github fan, so I'd vote for that, but I'm also fine with BitBucket since I can still use Git with it.

- Could somebody rip out YUI and replace it with jQuery?

 

I can give that a try...all that inline JS has always given me palpitations...

- I'd love to see somebody make a Rails or Django or AngularJS front-end as an alternative to XSLT UI code. It would just pass raw XML back and forth to stub XSLT running in XTF.

I'm interested in this too - if anyone would like to collaborate on this, let me know!

[Martin Haye]

Any other votes for Github vs Bitbucket? I plan to discuss with Lisa next week and we'll move the main repo somewhere more forkable.

--Martin

On Wed, Apr 2, 2014 at 1:59 PM, Hillel Arnold <hillel...@gmail.com> wrote:

Hi Martin,

Thanks for jumping in! 

 

- For easier forking we could move the main source code repo from SourceForge to BitBucket or Github. Or both. Preferences?

I'm a Github fan, so I'd vote for that, but I'm also fine with BitBucket since I can still use Git with it.

- Could somebody rip out YUI and replace it with jQuery?

 

I can give that a try...all that inline JS has always given me palpitations...

- I'd love to see somebody make a Rails or Django or AngularJS front-end as an alternative to XSLT UI code. It would just pass raw XML back and forth to stub XSLT running in XTF.

I'm interested in this too - if anyone would like to collaborate on this, let me know!

 

--Martin

[Bridger Dyson-Smith]

I'll vote for Bitbucket - it supports Mercurial and Git.

Thanks,

Bridger

[Seth.Public]

I think there is one major simplification that basically dwarfs everything else: Pull all the variables from all the files and place them in xtfCommon or create a new config file available to every file.

I just did some quick checking, and there are 1900+ variable declarations in xtf. Of these there are only 265 uniquely named variables.

I did not bother going into perfection, but it appears that all but about 80-100 of the remaining 1650 declarations are identical--they can be deleted. This number is a bit fluid because it doesn't take into account multiline declarations, but it is significant.

This would require writing new ifs for the variables that change in xtfcommon, but everything else would be much cleaner and easier to read/modify.

[Seth.Public]

I will be using bitbucket myself because of the free private repos, but the main point is GIT is it not? It seems like the choice depends on the XTF core team's preference, because we can use whatever site we want without complications as far as I understand.

[John A. Walsh]

I'm fine with anything that supports git. 

---

| John A. Walsh

| Associate Professor of Information Science

| Indiana University, 1320 East 10th Street, Bloomington, IN 47405

| Web: <http://johnwalsh.name> Voice: +1-812-856-0707 

[Francis Kayiwa]

On Sat, Apr 5, 2014 at 10:33 AM, Seth.Public <seth....@gmail.com> wrote:

I will be using bitbucket myself because of the free private repos, but the main point is GIT is it not? It seems like the choice depends on the XTF core team's preference, because we can use whatever site we want without complications as far as I understand.

+1

Whatever DVCS the core team picks will work for me. 

./fxk 

--

Vulcans worship peace above all.
		-- McCoy, "Return to Tomorrow", stardate 4768.3

[Seth.Public]

In terms of variables (and maybe params), I would just like to add that I would love to leave the xslt to actual transformations, and generate them from a java properties file with myVariable=myValue if that is possible. It might be complex to allow for variable assignment based on style sheet in use, etc., but it would cut out a bit of the xslt verbosity.

[dan haig]

Github

--

You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Conal Tuohy]

I agree the XSLT needs to be organised differently in order to decouple local customizations from core code.

For me the issue I had to deal with was TEI containing editorial markup (errors, revisions, corrections, deletions, abbreviations etc.)- you need these elements if you are dealing with manuscripts. In the instance I was working with, someone had already edited the components.xsl file, so I continued in that way, adding templates matching tei:sic, tei:corr, etc. But usually I would have used xsl:import instead. I would create a new stylesheet and add my new templates to it, and import the "stock" stylesheet into it. My templates can simply override any of the "stock" stylesheet's templates. I think xsl:import is a good way to manage the situation where there's a transformation that might need to be slightly tweaked in arbitrary way to suit local purposes. To support this, it would be convenient if all the customizable stylesheets in XTF (i.e. the "extension points") were shipped as a *pair* of stylesheets; e.g. an XSLT stylesheet called "tei.xsl" for transforming TEI to HTML, and another stylesheet called "local-tei.xsl" or similar, which contained an xsl:import pointing at "tei.xsl" and a comment saying "put your local customizations to the TEI transformation here - do not edit tei.xsl" - and nothing else. This will encourage local developers to keep their truly local customizations separate, and should simplify upgrades. If these "local" stylesheets were all in one part of the directory tree, that would also help to manage the customization as a separate thing.

Otherwise I think there's potentially a lot of value in extending the "pipeline" approach, where XSLTs are chained together; early stylesheets produce content, and later stylesheets are responsible for wrapping the content in navigational context, and later stylesheets are responsible for branding and linking to CSS etc. This I think corresponds to the "style-free" idea.

Conal

[Conal Tuohy]

I don't have a preference. Either is fine.

 

--Martin

To post to this group, send email to xtf...@googlegroups.com.

Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf...@googlegroups.com.

Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf...@googlegroups.com.

Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Jasper Bedaux]

I agree with Conal that the mechanism he describes with xsl:import and "local-tei.xsl" etc. is a good approach (better then overriding complete files which we are doing here right now).

However, my experience is that by overriding templates, in practice you are often duplicating hundreds of lines of code when you really only wanted to change a single line... this is because some of the templates (especially templates that generate HTML pages) in the default XTF XSL are quite large.

So for this approach to work conveniently (without duplicating too much code), some of the default templates need to be split up in multiple smaller templates I think.

E.g. if you want to change the line "<title>XTF: Search Results</title>", you will need to override at least two templates from resultFormatter.xsl that are each 100+ lines.

Maybe this is not a very good example because the title could probably be better defined in a config or language file, but you get the point.

--

[Martin Haye]

Agreed, somebody should do a deep refactor of the stylesheets, breaking things down into little overridable chunks.

--Martin

On Mon, Apr 7, 2014 at 8:02 AM, Jasper Bedaux <bed...@gmail.com> wrote:

I agree with Conal that the mechanism he describes with xsl:import and "local-tei.xsl" etc. is a good approach (better then overriding complete files which we are doing here right now).

However, my experience is that by overriding templates, in practice you are often duplicating hundreds of lines of code when you really only wanted to change a single line... this is because some of the templates (especially templates that generate HTML pages) in the default XTF XSL are quite large.

So for this approach to work conveniently (without duplicating too much code), some of the default templates need to be split up in multiple smaller templates I think.

E.g. if you want to change the line "<title>XTF: Search Results</title>", you will need to override at least two templates from resultFormatter.xsl that are each 100+ lines.

Maybe this is not a very good example because the title could probably be better defined in a config or language file, but you get the point.

--

You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.
To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Gary Browne]

Hi Martin (and others who have made great suggestions),

 

I’m all for these improvement suggestions, especially the local customisations ideas. Not sure on the best implementation strategy for this –Conal’s suggestion would be the easiest for those already familiar with the XSLT stylesheets but does “scatter” your customisations throughout the different directories. I guess you could just create a “local” directory and symlink or such to the individual local-%blah%.xsl files. Just thinking aloud really.

 

+1 for git but only because it’s what I use. Just took a look at bitbucket and it looks good too.

 

Cheers,
Gary

 

GARY BROWNE | Development Programmer
Library IT Services | Fisher Library F03                                                                                                                                                                                    
THE UNIVERSITY OF SYDNEY

T +61 2 9351 5946  | M +61 405 647 868  
E gary....@sydney.edu.au  | W http://sydney.edu.au

Sent from my plain old desktop computer.

CRICOS 00026A
This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments.

Please think of our environment and only print this e-mail if necessary.

[Seth]

Hey guys,

First of all thanks to the XTF team for the style we have. It has serves us all well for many years. With all this talk I just want to start by saying hats off and thanks.

I want to throw out a semi-concrete proposal that does not address the issue of overrides, but which I think is a step in the right direction. Fundamentally, I would like to see variables declared earlier so there is no need to go back and forth to deal with hit formatting etc., and I think it would be good to adopt a structure that better resembles the final product: a website. Thus I think we should restructure the folders as follows. I think you can see what I am getting at in terms of structure within the style sheets by that:

common (contains conf, profile (perhaps merged together and called common.conf or something), xtfCommon.xml)
lib (contains icons, scripts, css, docs, licenses)
indexer (contains xml and bin)
search (contains param (param/variables), transform (create xml), format (create html--get rid of brand folder and have head/foot here))
view (contains param (param/variables), transform (create xml), format (create html--get rid of brand folder and have head/foot here))
sru

data
index
web_inf
meta_inf

Along with this I would like to get rid of some subfolders in search and view, perhaps just by renaming things so that if they are all in one directory it is obvious what each file does.

[Martin Haye]

Hi Seth,

I like a lot of the ideas, but not all. What about if you make a little repo on github, and populate it with some dummy files? Then I or others could fork it and make a counter-proposal?

--Martin

--

[Seth]

Something similar to that was on my mind.

Hillel, since you started this thread and it sounds like you have done a large amount of work, does this sound like something you could easily merge your changes into, or would it be better to wait until you are done and then reorganize your code?

Martin, could you at least throw out the one or two things that just aren't going to make the cut? I could get closer to the goal that way.

Thanks! Seth

[Hillel Arnold]

Hi Seth,

The changes I've made are fairly cosmetic and could probably be merged into what you're proposing fairly easily, so I'd say go ahead and lay out your concept in code and I'll catch up with you!

Hillel

[Martin Haye]

Here are the ones that jumped out at me right away:

1. Can we toss SRU? The code is so ancient I can't believe it's working any more. Plus SRU is ancient.

2. Could "common" be called "conf"? I've been downloading and installing lots of packages lately, and almost everybody has a "conf" directory.

3. With normal packages, "lib" would contain library files only, e.g. jar files. What about using "static" for the css/icons/scripts, and some other dir for the docs/licenses?

4. What would be in indexer/ besides the textIndexer script?

--Martin

On Thu, Apr 10, 2014 at 12:30 PM, Seth <seth....@gmail.com> wrote:

Something similar to that was on my mind.

Hillel, since you started this thread and it sounds like you have done a large amount of work, does this sound like something you could easily merge your changes into, or would it be better to wait until you are done and then reorganize your code?

Martin, could you at least throw out the one or two things that just aren't going to make the cut? I could get closer to the goal that way.

Thanks! Seth

On Thursday, April 10, 2014 2:45:35 PM UTC-4, Martin Haye wrote:

[Seth]

1. done :)
2. done
3. static and info?
4. indexer with bin subfolder but also the xml config files - organizing by task here, so that from XTF_HOME each major task category is only one level down.

Should we change the default search url to "query", and then name that folder "query" to match the xml file naming convention? rename the files? leave as is?

[Gary Browne]

Hi all,

 

Firstly, as someone else recently said, THANK YOU to all the devs and supporters of XTF. It’s been a boon for us at University of Sydney Library.

 

I’m excited by all this action on the list and wanted to add some ideas if I may – so glad to see XTF going from strength to strength.

 

What about “public” instead of “static” (or other suggestions)?

 

Would it be possible for XTF to follow more of a MVC-type framework? Recently I’ve been working with Laravel 4 (PHP MVC framework) but I simply used dynaXML’s doc.view=content parameter to pull XTF content in through the controller and pass it to the view. Has anyone out there been working on similar goals?

 

Once again, thanks to all the XTF devs, you rock!

 

Cheers,
Gary

 

 

GARY BROWNE | Development Programmer
Library IT Services | Fisher Library F03                                                                                                                                                                                    
THE UNIVERSITY OF SYDNEY

T +61 2 9351 5946  | M +61 405 647 868  
E gary....@sydney.edu.au  | W http://sydney.edu.au

Sent from my plain old desktop computer.

CRICOS 00026A
This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments.

Please think of our environment and only print this e-mail if necessary.

 

From: xtf-...@googlegroups.com [mailto:xtf-...@googlegroups.com] On Behalf Of Seth

Sent: Friday, 11 April 2014 7:09 AM
To: xtf-...@googlegroups.com

[Jasper Bedaux]

I would like to add a few suggestions about the folder restructuring:

1. The "data" and "index" dirs should not be fixed, but configurable. (In our case e.g. we do not have them inside the webapp, because that makes redeployment of the webapp harder.) For this, some changes in the source code are necessary because "data" and "index" are hardcoded in a number of places.

2. Except for static web-related files (like CSS, JS, icons), everything else should be moved into WEB-INF. This is because it is only necessary for XTF to read e.g. the .xsl and .conf files server side. In the current situation, they can also be viewed publicly, which is undesirable for security (and some source code files could e.g. end up in Google etc.), see for example http://www.marktwainproject.org/xtf/style/crossQuery/queryParser/default/queryParser.xsl

One of my colleagues has implemented this move, for this to work, a change was necessary in the Java code:

http://sourceforge.net/p/xtf/code/ci/default/tree/WEB-INF/src/org/cdlib/xtf/servletBase/TextServlet.java#l275

he changed this line from

baseDir = baseDir + "/";

to

baseDir = staticContext.getRealPath(baseDir + "/");

Regards,

Jasper

[Seth]

in terms of mdualr use of content a là dynaXML content--I definitely agree. We should have one xtf template with header, head, section, footer, and then each template: facets, search results, search form, dynaxml, should not produce a full page but use this template. It should just be wrapped in a div with a class and ID so that we can use it easily with JS if we want. I think we should shoot for html %, since that's where the world is, and I hink we should remove as much as is possible from the java--it is best to have all the html easily editable.

In terms of source protection, I just use htaccess, which is what the security libraries I use do.

[Seth]

I was typing like a ferret:

in terms of modular use of content a là dynaXML content--I definitely agree. We should have one xtf template with header, head, section, footer, and then each template: facets, search results, search form, dynaxml, should not produce a full page but use this template. It should just be wrapped in a div with a class and ID so that we can use it easily with JS if we want. I think we should shoot for html 5, since that's where the world is, and I think we should remove as much as is possible from the java--it is best to have all the html easily editable.

[Conal Tuohy]

Dear XTF-users,

In line with the discussions of a few years ago, I have implemented a customisation layer for XTF, to make it easier for users to maintain their own custom version of XTF. 

The change is packaged as a pull request to the CDL's XTF repository on github, and is described here.

https://github.com/cdlib/xtf/pull/14

If you maintain a locally-customized XTF, please take a look at the change, and make any comments either here or on the pull request in github.

Thanks!

Conal

On Monday, 7 April 2014 09:34:38 UTC+10, Gary Browne wrote:

Hi Martin (and others who have made great suggestions),

 

I’m all for these improvement suggestions, especially the local customisations ideas. Not sure on the best implementation strategy for this –Conal’s suggestion would be the easiest for those already familiar with the XSLT stylesheets but does “scatter” your customisations throughout the different directories. I guess you could just create a “local” directory and symlink or such to the individual local-%blah%.xsl files. Just thinking aloud really.

 

+1 for git but only because it’s what I use. Just took a look at bitbucket and it looks good too.

 

Cheers,
Gary

 

GARY BROWNE | Development Programmer
Library IT Services | Fisher Library F03                                                                                                                                                                                    
THE UNIVERSITY OF SYDNEY

To post to this group, send email to xtf...@googlegroups.com.

Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf...@googlegroups.com.

Visit this group at http://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

[Martin Haye]

I like it. Really this is the way we should have set it up from the beginning, so that people could easily isolate their local changes from the distribution stylesheets. Any objections to merging Conal's changes? If I don't hear from anybody today, I'll go ahead.

--Martin

[dan haig]

Having taken a quick look, it seems like these 'local' sheets are just places where you can enter an override for any given xsl:template you want to customize, is that right?

.d

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+unsubscribe@googlegroups.com.

To post to this group, send email to xtf-...@googlegroups.com.

Visit this group at https://groups.google.com/group/xtf-user.

[Martin Haye]

Yes, that's exactly right Dan.

--Martin

[dan haig]

Cool. I created such a system in ours 9 years ago and proceeded to need it for only one thing, until just this week. I've generally hacked the crap out of the main sheets :-)

[Martin Haye]

So, looks like more than 2 years ago I said "If I don't hear from anybody today, I'll go ahead" [and merge Conal's customization layer]. Going to actually work on that today, plus another PR from James Howe.

A larger issue is that it's clear I'm not a very good maintainer for the XTF source code and need to expand the set of committers. I'll address that in a separate email.

--Martin

On Tue, May 16, 2017 at 3:07 PM dan haig <ha...@nlx.com> wrote:

Cool. I created such a system in ours 9 years ago and proceeded to need it for only one thing, until just this week. I've generally hacked the crap out of the main sheets :-)

On Tuesday, May 16, 2017, Martin Haye <r.c.mar...@ucop.edu> wrote:

Yes, that's exactly right Dan.

--Martin

On Tue, May 16, 2017 at 1:51 PM, dan haig <ha...@nlx.com> wrote:

Having taken a quick look, it seems like these 'local' sheets are just places where you can enter an override for any given xsl:template you want to customize, is that right?

.d

On Tue, May 16, 2017 at 3:30 PM, Martin Haye <r.c.mar...@ucop.edu> wrote:

I like it. Really this is the way we should have set it up from the beginning, so that people could easily isolate their local changes from the distribution stylesheets. Any objections to merging Conal's changes? If I don't hear from anybody today, I'll go ahead.

--Martin

On Mon, May 8, 2017 at 6:52 AM, Conal Tuohy <conal...@gmail.com> wrote:

Dear XTF-users,

In line with the discussions of a few years ago, I have implemented a customisation layer for XTF, to make it easier for users to maintain their own custom version of XTF. 

The change is packaged as a pull request to the CDL's XTF repository on github, and is described here.

https://github.com/cdlib/xtf/pull/14

If you maintain a locally-customized XTF, please take a look at the change, and make any comments either here or on the pull request in github.

Thanks!

Conal

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at https://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at https://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.

To post to this group, send email to xtf-...@googlegroups.com.
Visit this group at https://groups.google.com/group/xtf-user.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "XTF Users List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtf-user+u...@googlegroups.com.