Opened on 10/04/2017 at 04:30:16 PM

Last modified on 09/17/2019 at 12:27:03 PM

#5830 new change

Provide access to globals from filters

Reported by: juliandoucette Assignee:
Priority: P3 Milestone:
Module: Sitescripts Keywords:
Cc: wspee, kvas, jsonesen Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kvas)

Background

I can't define a global in globals and access it in filters. It's also not possible to access globals from other globals, which leads to code duplication sometimes.

What to change

I want to be able to access globals from filters and other globals. Example (only showing filter usage):

globals/example.py

example = 'example'

filters/examplify

def examplify(str):
  return '%s (%s)' % (str, example)

includes/example

<h1>{{ "My test" | examplify }}</h1>

output

<h1>My test (example)</h1>

Attachments (0)

Change History (5)

comment:1 Changed on 10/04/2017 at 04:34:43 PM by juliandoucette

Real world example: The language selector on the new abp.org contains a location code after the language name e.g. "English (US)". We already have a filter called to_og_locale which matches crowdin language codes to ISO locale codes (which include location codes). If I could define og_locales as a global then I could write a filter to provide *just* a location code (instead of a full locale) from a crowdin language. e.g.

def to_og_location(crowdin_language):
  if (crowdin_language in og_locales)
    return og_locales[crowdin_language].split('_')[-1]
  else
    return crowdin_language.split('_')[-1]

(I used two filters to solve this problem today e.g. locale | to_og_locale | to_og_location where to_og_location just blindly returns the split('_')[-1] of what it was given.)

Last edited on 10/04/2017 at 04:40:54 PM by juliandoucette

comment:2 follow-up: Changed on 10/05/2017 at 01:17:56 PM by kvas

What do you think about globals being accessible from other globals? It seems to me like this would be a reasonable piece of functionality to add to this ticket, and it doesn't seem to make it much harder, so I'd be interested to know if you find it a useful addition?

comment:3 in reply to: ↑ 2 Changed on 10/05/2017 at 01:49:43 PM by juliandoucette

Replying to kvas:

I think that it would be very useful to be able to access globals in globals. Please add that functionality to this ticket too if it is not too much trouble.

comment:4 Changed on 10/05/2017 at 09:04:35 PM by kvas

  • Description modified (diff)
  • Priority changed from Unknown to P3
  • Ready set

comment:5 Changed on 09/17/2019 at 12:27:03 PM by kvas

Dear stakeholders of this ticket,

I'm cleaning up Sitescripts tickets in Trac due to its phase out. This is one of the tickets that I could not myself close or move, so I need your input on it.

Please let me know if this ticket is still relevant for you and we can then discuss where it should be moved. If you think that this ticket is no longer relevant, you can write a comment explaining this or just ignore this message.

If I see now comments in the ticket on October 14, I will close it as rejected.

Best regards,
Vasily

Add Comment

Modify Ticket

Change Properties
Action
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
 
Note: See TracTickets for help on using tickets.