Jump to content

DZoneRick

Members
  • Posts

    15
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Cary, NC

Contact Methods

  • Jabber
    rick@dzone.com

DZoneRick's Achievements

Jr. Member

Jr. Member (3/6)

5

Reputation

  1. RT @suziechan286: "Read poems, even one a month" #MelanieReid in #TheTimes on what she wished she's known at 20

  2. @softwaregrove @dzone Glad to hear it stopped. DB sync can take a bit of time between systems.

  3. RT @chkal: Sweet. @DZone job offering hidden in the HTML source of their page. :)http://t.co/odJNHHRXT7

  4. RT @tedbauer2003: I wrote this for @AnswerHub on how to deal with silos in the workplace: http://t.co/5J9fGg0XCa #business #work #Silos

  5. Git Patterns and Anti-Patterns: Scaling from Workgroup to Enterprise http://t.co/Z0GHp49jqf via @dzone

  6. Awesome! I had no idea it was so easy to drop straight to SQL. You continue to surprise me with practical, useful solutions! Best, Rick
  7. Looks very sharp, Chris congrats! Is the page at http://chrisvaupel.de/leistungen/ constructed as a list of other pages? Cheers, Rick
  8. Very cool module, and it looks like it can do exactly what I want. My original question about php in fields was driven by my specific need to use the value of $config->urls->templates inside markup fields. It looks like MarkupShortcodes makes this relatively easy. Thanks!
  9. OK, I immediately went and tried it out, and the TinyMCE image plugin is merely hard-coding the path into the underlying html, which totally defeats the purpose. Here's an example of the html created by the TinyMCE plugin: <img src="/site/assets/files/1062/answerhub-logo-230x60.png" width="230" height="60" alt="AnswerHub" /> Hard-coding the path will only work UNTIL the site gets moved or the path changes, and then you're up a creek without a paddle. I'm looking for a simple, safe, reliable way to access $config->urls->templates and use it in markup stored in text fields. The TinyMCE plugin is not producing the outcome I was aiming for.
  10. OK, it's encouraging that you and others here feel that producing such a site wouldn't be a problem with PW. The fact is, after all, that I have decided to invest time, money and energy in adopting PW because it really seems to be the best of the available options. I'll tell you guys truly, though, that it's a damned shame there's not a killer PW gallery of killer PW sites. Nothing I have seen in the examples promoted on the PW website comes close to the tour-de-force range of that Desk.com site. It would have been super helpful to be able to browse through a lot more examples of PW sites, and managing such a gallery is precisely where PW excels!
  11. @apeisa, you and I both share an admiration for these solid strengths of PW, and I think we can also both agree that C5 does not provide the level of power and tooling that PW offers for structured data. But the real world has everything in it, both structured and unstructured. PW is not as amazing for the unstructured... yet. I have tons of respect for the passion and enthusiasm of the many PW champions and advocates here, and I'd like to point out that I am not attacking anything or anyone. This platform and community are awesome, and I mean to be a positive contributing member. I *DO* have lots of data that is beautifully well-suited for the PW strategy, hence my choice to adopt PW! But I also have several places where I just need some content, and it doesn't need to be distilled into anything nearly as abstract as template+data. This isn't a battle, and PW can definitely provide unparalleled support for template+data while at the same time making it easy to work with more direct markup or WYSIWYG content. The use-case that spurred me to create this thread was nothing elaborate, and it wasn't horrible or bad or any of the other stuff some of the folks above would seem to want to suggest. I merely hit a wall that I wouldn't have hit if I could have more easily used a tag/variable/symbol in my markup to get to the directory pointed at by $config->urls->templates. Mountain from molehill?
  12. Honestly, no, I did not know this. Thank you for the tip, and I will read that thread promptly. I'm a little skeptical of TinyMCE because it always seems to add or remove something in its efforts to be WYSIWYG. I was trying the ACE Text Editor module instead. So, how are the images being inlined in TinyMCE? Is there some kind of underlying tag semantics we can use directly from within non-WYSIWYG markup?
  13. I imagine we've all heard the old saying about "When the only tool you have is a hammer, then all problems start looking like nails." I am a longtime advocate of separation of data from presentation, and I think ProcessWire's templating approach is really cool. That said, however, there are a lot of times when it isn't practical or worthwhile to make much effort to separate your data into a bunch of separate fields and a template and then put them back together. If I am writing a journal entry I may want to write a paragraph, insert an image inline with the text, write another paragraph and embed a Youtube video. I don't want to create a new page type with a text field or two, an images field, a movie field and a template to put them all together. I just want to sandwich some html markup with a header and a footer and move on. ProcessWire is amazing for handling situations where you expect to manage a lot of repetitive "pages" (data structures) of a given type. For lists of skyscrapers, villas or lists of just about anything this CMS is the bomb - honestly it is amazingly clean! It's a little less clear that it is worthwhile to use a "template" approach when you're just making a one-off page or content block. Not all web content needs to be reduced to an abstraction of data and template before you can use it - this is the hammer issue. Even if you load the images in a journal entry into the images field of a typical page template, how are you supposed to access them from within your rich text or markup? A lot of content doesn't need to be set up for easy re-use, it just needs to be conveniently used once. This is where I'm struggling a little. All in all, I think the ProcessWire approach is fresh and powerful, but it would be good to be able to put some images and scripts on the filesystem and discover that they are available below "/site/templates/mystuff". One of my competitors is Salesforce's Desk.com, and they have an outrageously good sales website. A site like this would be really tough to develop in ProcessWire since almost everything on the site is handcrafted, single-use content. Not much of their site is well-suited for templates, but the whole thing is pixel perfect. There's a place in the world for content that isn't generated by invoking a template on a set of page data. ProcessWire is an awesome tool, but not all content is so rigidly aimed at separation into data and templates. Some content is just content, use it once and keep moving. Lots of other CMS's make that easy, but they don't excel at the structured repetitive stuff like ProcessWire does. It would be great if ProcessWire also made it easier to produce those conventional throwaway pages, too.
  14. There is nothing horrible about wanting a way to use your site's templates and static file resources from within markup in a body field. @Wanze's method above is clever and will likely work, but it would be so much better for this to simply be present at the system level.
×
×
  • Create New...