Hi Jeremy
The one means freeway has seen something on that page that has already got that id, so it shoves a 1 after it.
If you create a new document and add an element to the master page. Then look at the index page. You should see the element is not automatically numbered. It’s named the same, with no number … so my guess is you have managed to detach something and then created a duplicate item in there somehow… anyway that what I have found when I have had the same issue.
max
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Indeed, when I go to an existing master and create a new text field, for example, it puts that horrid “1” after the Name/ID on the Master! And then when I go to a page that has that text field appearing (from the Master), it too has the “1”. That wouldn’t be so bad if all the items could retain that name. But sometimes things do get detached. And if I could reattached individual items to the Master, rather than reapply Master to the whole page which messes a lot of things up, then that too would be a solution.
But as it stands now, I need to reference specific names in my JavaScript, and when names change, it means I must change my JS! That is driving me mad.
I want the power in Freeway to name things as I want. I want to tell Freeway, “I don’t care what YOUR reason is for adding that infernal “1” at the end, I do NOT want that “1” so fix it, buddy!” Software needs to be a tool that does the grunt work for me.
–“JAMES” Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I remember a scenario from the past, but honestly can’t recall it at all. It happened by inheriting a Freeway-doc to a new project (save under?). Then I renamed the style-sheet and things started getting weird. As far as I remember, it happened to me too, added items having been renamed by something.
We discussed it here and some users made the same experience. But as far as I know, we never came to a conclusion nor on how to fix it. It simply seemed, that there were some ghosty styles haunting through the document (if not to say “bug” by whatever).
If you start a simple doc from scratch, this shouldn’t happen at all. So it must have to do with the current project.
And here is a vague guess - something worth to try (or think about). Save the project as “template” and restart the project new → from template. Probably the ghost decides not moving to this freshly new facsimile.
ID is the leading and major concept in Freeway. Freeway takes care of us not screwing things up (creating invalid code). In a pretty strong way.
Since working with another application, I settled my horse entirely new. Towards classes and occasionally to IDs if required. BUT - it’s my responsibility making things correct. The app doesn’t help me much.
Furthermore, there is another thing coming into my mind:
The extended dialogue (Tab DIV). I know it’s much more of work. But in there, you can overwrite Freeway’s internal given ID towards the new. Especially if you depend on a specific ID (for JS) this is a way out of the dilemma.
Hope it helps somehow!
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Freeway renames items to avoid clashes with other items that have the same name.
In the case of master pages, it prevents you from using names that clash with other items on the master page - and also from using names that clash with items that are not on the master page but are on one of the instance pages that derive from the master.
E.g.
Draw a textfield on an instance page and call it “textfield”
Draw another textfield on the master page and call it “textfield”
Freeway renames the textfield on the master page as “textfield1” - to prevent you from having two items called “textfield” on the instance page (since you’re not supposed to have two items with the same ID on a single page).
To prevent this happening, you need to look through your instance pages and find the items that have conflicting names (and rename them or remove them).
Indeed, when I go to an existing master and create a new text field, for example, it puts that horrid “1” after the Name/ID on the Master! And then when I go to a page that has that text field appearing (from the Master), it too has the “1”. That wouldn’t be so bad if all the items could retain that name. But sometimes things do get detached. And if I could reattached individual items to the Master, rather than reapply Master to the whole page which messes a lot of things up, then that too would be a solution.
But as it stands now, I need to reference specific names in my JavaScript, and when names change, it means I must change my JS! That is driving me mad.
I want the power in Freeway to name things as I want. I want to tell Freeway, “I don’t care what YOUR reason is for adding that infernal “1” at the end, I do NOT want that “1” so fix it, buddy!” Software needs to be a tool that does the grunt work for me.
Thank you for the suggestion, but creating a template is more work than I want to do, and using the Extended Dialog as an override would probably work, but it forces me to have to remember that I am incorporating such “HACKS” into my site. My suggestion to Jeremy below is better, I think. Perhaps you will agree…
Jeremy,
Thank you for the explanation. I understand how it works now, but I still think that I should be empowered to easily take control. Meaning, the Master should be THE MASTER. And I should be MASTER of the MASTER! If I tell a Master page to name a Master page item with a specific name, why have Freeway alter all names that conflict so the Master will obey my command? Why should I have to do such manual labor so as to appease the naming gods?
If the Master renames items to avoid conflicts, that could potentially create other problems, I agree. But the solution to that is simple (conceptually). Have Freeway present me with a dialog that shows me all items that were renamed and allow me to visit each and every one so I have the chance to see if that renaming creates any new problems, and if it does, I can then fix them one by one. No more “digging” and manual labor required.
I believe this approach is better than the existing “dig into every single web page and find what may or may not be there” approach. Sure, it requires a modification to Freeway, but I think it would be a good one.
Best,
James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Whatever I do and whatever I say, whether if it is the nice guy or the bad boy, I’ll do it wrong.
It’s a simple matter of fact, that you guys expect the no-brainer no-coder application. But if things are NOT running as you expect, it’s either wrong.
SP did a great job ensuring the Master/Child relation which didn’t work in the past. Now it does - even for inflow constructions.
The concept behind is simple:
You need to separate Master-items (m1) from Child-Items (item1) and establish a master.css to ensure this. On plus you have the child.css. This ensures having each element only once on a page by simply adding master.css + child.css. And on top, each m1 can appear once on each other child-page of your site.
Make yourself clear what “Master-Pages” are and when you should place elements on a master. That’s your job as Master of the master!!!
And when I say EXTENDED dialogue, it is in fact YOUR weapon of choice if it comes to:
“I need more of the control”
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Hi James
Thomas and Jeremy are correct; Freeway handles the naming numbering convention for a good reason… people cock it up and then blame the software. I am not saying it’s perfect, but I see so many faults in people Freeway artwork that to let that amount of control e.g. I am the master and I what I say goes is a recipe for a right pile of dog mess.
The easier route would be to say to your self: “heck there is something in that freeway site that I have either missed or is conflicting so rather than fight it and spend a massive amount of time trying to track it down, why don’t I use a class with the javascript”. That way there’s no conflicts, it has no effect with the internal machinations of the Freeway naming convention, and you can separate out your JS requirements from freeway own internal naming control.
Max
PS Thomas, you are always the bad cop :o)
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I think Freeway should avoid styling using ID’s and use classes. That way you can apply (the same) classes to items that should look the same. Coffeecup does an amazing job in this, and you can see the modifications you do on one item reflect throughout the site; it’s all in the classes.
Second; you can create a symbol from any item; this means that all content within that item on all pages will automatically update as soon as you make changes in it on any page, like footer, header or whatever object you have within your layout that has to be the same on every page. I remember an action that kind of does the same within Freeway.
It’s just simplicity. Simplicity always works in your favour when it brings the same result as any other workaround.
– Richard
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Fiddling around with Extended dialogs to work around quirky problem (in some cases “bugs”) is NOT “simple.” All I am asking for is simplicity. Extended dialogs and such are not “in your face” boxes like the Inspector palette, so if you use such HACKS to work around problems or to add classes and such, and then you don’t update a site in a few months and come back to it, you will surely not remember where all your deeply hidden hacks are located. Making copious notes is potential a solution but a bother.
I want simplicity. I just want to use an ID or Class in combination with my JS to do things. And I want to take advantage of Master content to save me time. Being a detective cop trying to sleuth out WHY a silly “1” is being added (or a “2”) to the end of my Name/ID is not simple.
Let’s keep it simple. But that will require a change to Freeway.
–James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
The Google Maps action is built into Freeway, and it has a tiny but important problem that needs to be fixed before you release a new version of Freeway. The problem is that HTTPS is rapidly becoming the protocol of choice now, but the Google Maps action still uses HTTP. That’s fine until Freeway users move to a HTTPS site like I have. When that occurs, the Google Maps content is blocked by the browser because the page is trying to access it via HTTP rather than HTTPS.
All you need to do is just open the “Google Map.fwaction” and edit the 3 “http://maps.googleapis…” lines to be “https://maps.googleapis”. I am doing this manually and it works, but I don’t want to keep doing it every time a new version of Freeway comes out. If you update the code (taking only seconds to do) on your end, the problem is solved once and for all.
–James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
The hard I seek, I can’t find the “Google Map.fwaction” within the Freeway package. All I find is the “Google Suite.fwactionb” and in there, I can’t find any href of relevance. Could you please be more precise on this?
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Open Google Suite.fwactionb, then within that, you want Contents/Resources/Actions/Google Map.fwaction
Walter
On Mar 15, 2017, at 10:11 AM, Thomas Kimmich email@hidden wrote:
The hard I seek, I can’t find the “Google Map.fwaction” within the Freeway package. All I find is the “Google Suite.fwactionb” and in there, I can’t find any href of relevance. Could you please be more precise on this?
Another Freeway enhancement I think would benefit all users pertains to this:
That page recommends the following as a solution…
And this online tool even provides one-click generation of critical CSS:
Here’s the free version:
Obviously, it would be nice if Freeway could handle this for web designer, especially since Freeway already has a Document Setup feature to allow “External Style Sheets.” Many of us choose to use external CSS files for good reason, but when used the inevitable result is a *.css file (or files) that blocks rendering. So having Freeway prevent that, without any grunt-work and HTML Markup code injection on our part, would save a lot of time and improve our Freeway sites too.
–James Wages
freewaytalk mailing list
email@hidden
Update your subscriptions at:
It’s basically about loading “critical” stuff - or figurative spoken: stuff above the fold, right?
My personal view on this is, that it might end disastrous, letting an application decide which stuff is critical to load and which isn’t (exclude/include). It’s sometimes necessary, sometimes not. It’s designer’s decision.
The good news on this is, that it can be handled in Freeway. I’m using Max’s CSS: ID2Class action for this (but I think Tim has something similar). This action can do a lot of helpful things as long as you know what you’re doing. One of the options is to “turn the ID into a class-style” and as far as I remember, selecting this option, the action automagically adds those classes into the before-end head part.
It’s an item-action, so you then can decide, which elements will be loaded first and all the rest will be served by the style-sheet(s).
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I am aware of that Action, but I don’t see how it helps automate the process for me.
This sort of automates the process (for a fee), but you must do it on every single page:
Having Freeway do it would alleviate that burden.
That’s also why I use an Action to generate site maps with Freeway. None of the free online site map generators hold a candle to what the SiteMapper action can do. Makes it so easy. But !@#$%! That freaking action perpetually dirties all the pages in my site. I love that action and I hate it too.
–James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Just to clarify the class 2 id action (the new one) can now convert the id to a class on the html tag and it converts the id style found either in the head or in external style sheet… we had a rethink about how to do it because I didn’t want duplicate id and class styles with the same attricutes
anyway Thomas may be one of the few people who has that specific action so I better update that on action forge
Kind regards Max
freewaytalk mailing list
email@hidden
Update your subscriptions at:
thanks for this. I must admit that I’m using the “old” version - the one keeping the redundant ID styles cause I ran into some serious troubles (can’t recall which to be honest). If I got some time, I’ll have another look into this.
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
The limitation on the new action is I can’t change any styles on the master style sheet which is generated from master items.
Naturally, the actual HTML tag ID can be converted to a ‘CLASS’, but its associated ID style in the master CSS style sheet is unaffected because the master style sheet is a read-only affair.
I could try to do something whereby if the style of the item is written into the master style sheet method; then you would choose to use the older action method which duplicates the style and adds it back as a class style within the head. That way it should work but I haven’t looked into it.
Kind regards Max
freewaytalk mailing list
email@hidden
Update your subscriptions at: